我目前正在开展一个涉及三个不同网站的项目,这些网站具有许多常用function。 目前,常用function被放置在充满用户控件的不同网站中。 问题是在多个网站上共享用户控件。 环顾SO和其他网站,唯一的解决方案似乎是使用虚拟目录。 由于这是一个可行的解决方案(我们现在就是这个),它似乎不是一个“干净”的解决方案。 在不同站点之间共享通用function(包括GUI / HTML)存在哪些“最佳实践”? (例如)是否可以创建单个Web应用程序项目并将子目录(每个子目录都有自己的web.config)部署到不同的生产环境中?
我有一组依赖于其他项目的项目(你可以说实用程序),问题是我每次更改这些实用程序中的任何一个的代码时,我的同事需要采用最新的代码并在他们的机器上构建以使用最新的组件。 有一个很好的标准解决方案吗? 或者只是将dll集中在共享文件夹上? PS: 我们正在使用MS source safe 2005,我不希望我的同事每次都使用源代码并在他们的机器上构建,因为他们只需要二进制文件而不是代码。
作为我们开发生命周期的一部分,我们在项目中针对C#源运行了许多过程。 这些进程由GUI驱动,该GUI当前读取* .csproj文件以查找项目中使用的源文件。 这很好用。 我们现在有一个新要求,即提供一些需要调用Web服务的validation过程。 需要为Web服务提供一些特定于项目的凭据。 理想情况下,我们可以在* .csproj文件中输入和存储这些凭据,但我没有看到扩展它的方法 – 是吗? 我们真的不想引入新的配置。 如果我们可以帮助它,只为这些设置提供文件。 是否有可能存储这样的信息是* .csproj文件,如果没有其他地方可以放置它。 谢谢
脚本 考虑一个包含4个项目的解决方案: 1)ProjectSql:这是一个项目,其编译输出设置为Library ,它负责访问SqlServer数据库并执行某些操作。 最终的库将能够提供API,以便管理最终应用程序的持久性。 2)ProjectWCF:这是一个项目,其编译输出设置为Library ,它负责定义服务合同,数据合同和服务实现,以便让我的应用程序托管服务。 3)ProjectMiscellaneous:这是一个项目,其编译输出设置为Library ,并且负责为其他事物提供API。 4)ProjectApp:这是一个项目,其编译输出设置为Executable (Exe) ,它负责创建我的应用程序的业务逻辑。 假设这是一个简单的控制台应用程序。 这个项目引用了所有其他项目。 假设:考虑每个项目都有自己的配置文件。 例如,ProjectSql定义连接字符串以连接到数据库等等…… 问题:配置 好吧,我的问题如下:考虑我的应用程序项目ProjectApp使用ProjectSql,好吧,每次调用ProjectSql中的操作都需要连接到数据库,在这些调用中引用ProjectSql配置文件来获取连接字符串(一个简单的调用System.Configuration.ConfigurationManager…. )。 我认为如果我的ProjectApp使用自己的配置文件调用ProjectSql中的操作,那么该操作将引用它自己的配置文件。 我的问题是: 我说的是真的吗? 配置文件是否尊重项目层次结构。
我有.csproj项目,我想引用其他项目.xproj ,一切看起来都不错但是当我尝试构建解决方案时,我不能因为.dll丢失了。 当我从\bin\release\net452\…引用.dll ,一切都还可以。 如何解决? 编辑:我不是在寻找变通方法 – 现在我正在使用gulp.move()。 它工作正常但感觉很脏……
我们目前有一个快速增长的C#代码库。 目前我们有大约10个项目,分为通常的类别,common / util东西,网络层,数据库,ui组件/控件等。 我们遇到偶尔的循环依赖,其中项目x依赖于y中的某些东西,反之亦然。 我们正在考虑将项目折叠为一个,只使用结构文件夹/命名空间进行管理。 我们有一个Java项目,当然只使用文件夹/包进行组织,所以我们不确定有多个项目带来的好处(如果有的话)。 我们的项目都不需要特殊的项目属性,除了主要运行项目,我们可以将它们分开(并且非常薄)。 有没有人有任何先前的经验,为什么一个项目比多个项目更好/更差,并可以建议最好的方法? 而且循环依赖的任何问题在这两种方法中都很有用。 任何输入赞赏。
我有一个包含多个项目的解决方案,包括NUnit Test项目。 所以解决方案看起来像这样(使用通用名称,这些不是实际名称): + Solution + Project1 + Project1.Test + Project2 + Project2.Test + Project3 + Project3.Test … 当我从Visual Studio中单击“开始调试”时,我想通过NUnit GUI或控制台应用程序运行所有NUnit测试。 现在,我所做的是添加一个名为TestRunner的新类库,并将其设置为StartUp项目(我已经读过,我真的不需要这样做,我可以右键单击该项目并单击’Debug >开始新实例’)。 然后在Debug页面的项目属性中,我将’Start Action’设置为’Start external program’并选择nunit-console.exe(看起来nunit.exe GUI不支持多个程序集作为输入参数)。 然后在’命令行参数’中输入每个项目的路径。 像这样: 设置http://sofzh.miximages.com/c%23/30ku3xu.jpg 这似乎工作正常,但我想知道是否有更好的方法来做到这一点(也许我不需要额外的项目,或者可能有一种更简单的方法从Visual Studio中运行多个NUnit测试项目)。 任何改善这一点的建议都将受到赞赏。 运行NUnit 2.5.9和Visual Studio 2008。
我正在创建一个库,用于我正在构建的应用程序。 我正在建立一个类似于下面的名称空间结构。 MyNamespace.Validation MyNamespace.Reports MyNamespace.Transactions MyNamespace.DataImport etc… 最佳做法是为每个子命名空间创建一个包含多个项目的解决方案,或者为每个子命名空间创建一个包含多个类文件的项目? 谢谢。
非常直言不讳,但有人知道如何将visual studio 2008项目转换为visual studio 2003,我的意思是向客户提供一些东西,他们只在2003年工作。 对不起有人提出了一个非常好的观点,用什么语言,C#就是答案。 我在谷歌上做了很多搜索,往往只提出2003-> 2008而反之亦然,我非常感谢任何帮助。
现在我以不同的方式在SO上看过这个问题,但令人惊讶的是不是这种forms: 我有一个需要相互通信的多个Web服务(项目)的解决方案。 发布后,这些Web服务中的每一个都可能最终位于具有不同数据库的不同计算机上。 为了告诉每个Web服务所有其他Web服务的位置,我想在开发期间维护一个配置文件。 我希望在发布配置后出现在每个已发布的项目中。 我希望配置文件在发布后可以编辑,这样我就可以快速迁移某个Web服务,然后只编辑其他Web服务的所有配置文件。 我不想在数据库中这样做,对于配置文件,它自己也应该保持对数据库的连接设置。 我遇到了以下想法/想法/问题: 我有一个名为’common’的dll项目,由其他项目引用。 让我们给它一个shared.config并在该项目中构建一个类,可以通过执行System.Configuration.ConfigurationManager.OpenExeConfiguration(“shared.config”)来读取System.Configuration.ConfigurationManager.OpenExeConfiguration(“shared.config”) 。 只需要确保shared.config将与DLL一起发布。 我赞成这个解决方案,因为它还允许我在每个项目中保留web.config,只有项目特定的设置。 并让shared.config具有共享设置。 但是,我在读到这一点时,不应该轻易考虑这一点,并且可能会产生一些不必要的副作用,例如文件访问问题; 虽然我想知道这是否适用于我的情况。 此外,我想请求您的帮助,如何实际实现这一点,因为我不认为Visual Studio支持开箱即用的DLL项目的app.config。 我还考虑过在解决方案项中创建一个shared.config文件。 然后在每个项目中链接该文件。 在每个项目的Web.config中,添加: 指向该项目中的链接文件。 虽然我找不到任何理由不这样做,但首先实施失败了。 看来(至少在开发过程中),c#找不到链接的shared.config文件。 我猜测创建链接文件后链接文件不会立即完成,也不会维护,但文件只会在我发布时复制到项目中。 因此在开发期间丢失文件。 它是否正确?