いくつかの共通コードがある2つのソリューションがあるので、それを抽出してそれらの間で共有したいと思います。さらに、他の人に役立つ可能性があるため、そのライブラリを個別にリリースできるようにしたいと考えています。
- Visual Studio 2008でそれを行うための最良の方法は何ですか?
- プロジェクトは複数のソリューションに存在していますか?
- 個別のコードに個別のソリューションはありますか?
- ソリューションは別のソリューションに依存できますか?
いくつかの共通コードがある2つのソリューションがあるので、それを抽出してそれらの間で共有したいと思います。さらに、他の人に役立つ可能性があるため、そのライブラリを個別にリリースできるようにしたいと考えています。
回答:
プロジェクトは複数のソリューションから参照できます。
ライブラリまたはコアコードを1つのプロジェクトに配置し、両方のソリューションでそのプロジェクトを参照します。
2つのプロジェクト間でコードファイルを「リンク」できます。プロジェクトを右クリックし、Add
->を選択Existing item
して、Add
ボタンの横にある下矢印をクリックします。
私の経験では、リンクはライブラリを作成するよりも簡単です。リンクされたコードは、単一のバージョンの単一の実行可能ファイルになります。
あなたはすることができます1つのプロジェクトを複数のソリューションに含めるます。プロジェクトには、そのソリューションが含まれているという概念がないと思います。ただし、別の方法としては、最初のソリューションを既知の場所にビルドし、コンパイル済みのバイナリを参照する方法もあります。これには、リリース構成でビルドするかデバッグ構成でビルドするかに基づいて異なるバージョンを参照する場合に少し作業が必要になるという欠点があります。
あるソリューションを別のソリューションに実際に依存させることはできないと思いますが、カスタムスクリプトを使用して適切な順序で自動ビルドを実行できます。基本的に、共通ライブラリを、NUnitなどの別のサードパーティの依存関係であるかのように扱います。
次の手法を使用して、ワイルドカードをインラインで使用できます(これは、@ Andomarのソリューションを.csprojに保存する方法です)。
<Compile Include="..\MySisterProject\**\*.cs">
<Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
入れて:
<Visible>false</Visible>
MySisterProject
上記のように「仮想の既存のアイテム」フォルダーにアイテムを追加または削除した場合に、ファイルを非表示にするか、ワイルドカードインクルードが展開されないようにする場合。
<Import
.csprojファイルに編集された.targetsファイルなどが、ソリューションをリロードするまでキャッシュされることです。
単純に、共通コードを含む別のクラスライブラリプロジェクトを作成します。それを使用するソリューションの一部である必要はありません。それを必要とするプロジェクトからクラスライブラリを参照します。
唯一のトリックは、プロジェクトを参照するためにファイル参照を使用する必要があることです。これは、プロジェクトを参照するソリューションの一部ではないためです。つまり、実際の出力アセンブリは、それを参照するプロジェクトを構築する誰もがアクセスできる場所に配置する必要があります。これは、たとえば、アセンブリを共有に配置することで実行できます。
同じプロジェクトを複数のソリューションに含めることもできますが、将来、問題が発生することが保証されます(たとえば、ディレクトリを移動すると相対パスが無効になる場合があります)。
何年もこれに苦労した後、ようやく実用的なソリューションを思いつきましたが、ソース管理にSubversionを使用する必要があります(これは悪いことではありません)。
ソリューションのディレクトリレベルで、ソリューションに含めるプロジェクトを指すsvn:externalsプロパティを追加します。Subversionはリポジトリからプロジェクトをプルし、ソリューションファイルのサブフォルダーに保存します。ソリューションファイルでは、相対パスを使用してプロジェクトを参照できます。
時間があれば、詳しく説明します。
svn:externals
までに、リポジトリへのハードリンク。リポジトリを移動しても、外部リンクは引き続き古いリポジトリを指しています。
関連する2つの主なステップは
1- C ++ dllの作成
ビジュアルスタジオで
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**
このオプションはダイナミックライブラリ(.dll)で、ソリューション/プロジェクトを今すぐビルドする必要があります。
first_dll.dllファイルがDebugフォルダーに作成されます
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#プロジェクトで使用しました。
内部NuGetサーバーをホストし、他のプロジェクトで内部および外部で共有される共通ライブラリを共有できます。
さらにこれを読んで
2つの異なるプロジェクトタイプ(つまり、デスクトッププロジェクトとモバイルプロジェクト)の間でコードを共有しようとしている場合は、共有ソリューションフォルダーを調べることができます。現在のプロジェクトでは、モバイルプロジェクトとデスクトッププロジェクトの両方で、1つのファイルだけにある同一のクラスが必要であるため、これを行う必要があります。この方法を使用すると、ファイルがリンクされているプロジェクトのいずれかが変更を加えることができ、すべてのプロジェクトがそれらの変更に対して再構築されます。
プロジェクト間でコードを再利用する場合、「既存のファイルリンクの追加」を使用する非常に良いケースがあります。これは、異なるバージョンの依存ライブラリを参照してサポートする必要がある場合です。
異なる外部アセンブリへの参照を使用して複数のアセンブリを作成することは、コードを複製したり、ソースコード管理でトリックを利用したりすることなく、簡単に行うことはできません。
開発と単体テストのために1つのプロジェクトを維持し、それらの外部アセンブリの異なるバージョンを参照するアセンブリを作成する必要がある場合は、既存のファイルリンクを使用して「ビルド」プロジェクトを作成するのが最も簡単だと思います。
VisualStudio 2015以降、すべてのコードを1つのソリューションに保持する場合、共有プロジェクトを追加してコードを共有できます。次に、コードを使用する各プロジェクトのこの共有プロジェクトへの参照と、適切なusingディレクティブを追加します。
これで、共有プロジェクトを使用できます
共有プロジェクトは、複数のアプリケーション間で共通のコードを共有する優れた方法です。Windows8.1ユニバーサルアプリ開発の一環としてVisual Studio 2013で共有プロジェクトタイプを使用した経験はありますが、Visual Studio 2015ではスタンドアロンの新しいプロジェクトテンプレートです。コンソール、デスクトップ、電話、ストアアプリなどの他のタイプのアプリで使用できます。このタイプのプロジェクトは、単一のプラットフォームで複数のアプリケーション間で共通のコード、ロジック、コンポーネントを共有する場合に非常に役立ちます。これにより、プラットフォーム固有のAPIやアセットなどにアクセスすることもできます。
詳細はこちらをチェック