我有两个有一些公共代码的解决方案,所以我想把它提取出来并在它们之间共享。此外,我希望能够独立地发布这个库,因为它可能对其他人有用。
用Visual Studio 2008最好的方法是什么? 一个项目是否存在于多个解决方案中? 对于这段单独的代码,我有单独的解决方案吗? 一个解决方案能依赖于另一个解决方案吗?
我有两个有一些公共代码的解决方案,所以我想把它提取出来并在它们之间共享。此外,我希望能够独立地发布这个库,因为它可能对其他人有用。
用Visual Studio 2008最好的方法是什么? 一个项目是否存在于多个解决方案中? 对于这段单独的代码,我有单独的解决方案吗? 一个解决方案能依赖于另一个解决方案吗?
当前回答
创建一个包含所有常用功能的dll类库是个好主意。无论其他解决方案如何,每个解决方案都可以独立地引用此dll。
事实上,在我的工作中,这就是我们资源的组织方式(我相信在许多其他地方也是如此)。
顺便说一下,解决方案不能显式地依赖于另一个解决方案。
其他回答
您只需创建一个单独的Class Library项目来包含公共代码。它不需要成为任何使用它的解决方案的一部分。从任何需要它的项目引用类库。
唯一的技巧是,您将需要使用文件引用来引用项目,因为它不会是引用它的解决方案的一部分。这意味着实际的输出程序集必须放置在任何构建引用它的项目的人都可以访问的位置。例如,这可以通过将程序集放在共享上来实现。
涉及的两个主要步骤是
1-创建c++ dll
在visual studio
New->Project->Class Library in c++ template. Name of project here is first_dll in
visual studio 2010. Now declare your function as public in first_dll.h file and
write the code in first_dll.cpp file as shown below.
文件代码
// first_dll.h
using namespace System;
namespace first_dll
{
public ref class Class1
{
public:
static double sum(int ,int );
// TODO: Add your methods for this class here.
};
}
Cpp文件
//first_dll.cpp
#include "stdafx.h"
#include "first_dll.h"
namespace first_dll
{
double Class1:: sum(int x,int y)
{
return x+y;
}
}
检查这个
**Project-> Properties -> Configuration/General -> Configuration Type**
这个选项应该是Dynamic Library(.dll),现在就构建解决方案/项目。
在Debug文件夹中创建first_dll.dll文件
2-在c#项目中链接它
开放c#项目
Rightclick on project name in solution explorer -> Add -> References -> Browse to path
where first_dll.dll is created and add the file.
在c#项目的顶部添加这一行
Using first_dll;
现在可以在某些函数中使用下面的语句访问dll中的函数
double var = Class1.sum(4,5);
我在VS2010的c++项目中创建了dll,并在VS2013的c#项目中使用。它工作得很好。
将一个项目包含在多个解决方案中是一个非常糟糕的主意。
假设您在SolutionA和SolutionB中都包含了一个共享类库项目。
现在,如果您在解决方案a中工作,并在共享中进行了突破性更改,会发生什么?然后您将在解决方案a中得到一个构建错误,这可能很容易修复。但是你不会注意到你在solutionb中也弄坏了一些东西。您的构建服务器可能会告诉您—但这已经太迟了。在发布代码之前,您需要知道这些。
只有两个好的解决方案:
让Shared成为一个可以实际共享的nuget包,并使用semver来控制破坏性更改的影响。这可能会产生一些您不想要的开销。 创建一个单独的解决方案,其中包含来自solutiona和SolutionB的Shared和所有依赖的项目。如果您有许多不相关的项目依赖于sharedd,那么这可能不是最好的解决方案,然后您应该使用nuget方法。
您可以在多个解决方案中包含一个项目。我不认为一个项目有属于哪个解决方案的概念。然而,另一种替代方法是将第一个解决方案构建到一些众所周知的地方,并引用已编译的二进制文件。这样做的缺点是,如果您想根据您构建的是发布配置还是调试配置来引用不同的版本,那么您将需要做一些工作。
我不相信您可以让一个解决方案依赖于另一个解决方案,但是您可以通过自定义脚本以适当的顺序执行自动构建。基本上把你的公共库当作另一个第三方依赖,比如NUnit等。
在另一个项目中包含一个项目的类文件的一个更简单的方法是在现有解决方案中添加该项目,然后在现有项目中添加新项目的DLL引用。最后,您可以通过在任意类的顶部声明using指令来使用添加的类的方法。