Hi Andrey and all following this and
this and
this, I hate to be the one to throw a spanner in the works but I have had a lot of issues with One-Size-Makes-All projects that import project settings when the main project uses Nuget packages, or if it imports a project as a reference. When the .NET framework changes for your main project breaks the Nuget package because the
<HintPath> to the Nuget packages depend on the .NET framework when the package is added and so do their dependent packages in a lot of cases. The Microsoft BCL portable class library (which many Nuget packages seem to use) adds more recent .NET functionality to
.NET 4, is a big problem in this situation - that is an
issue with CADtest at the moment, it builds with warnings about conflict in referenced assemblies because it was originally a .NET 4.0 project and is lately a .NET 4.5 project.
I'm still thinking this one through, perhaps a way is to set up some Nuget host projects that use different versions of .NET and set those projects as conditional references to the main project(s) depending on the version of NET they use. I am just thinking out loud with that - I really don't think it will work.
Perhaps separate projects for each separate build is the most simple and maintainable answer. You can still re-use the same code by editing the CSPROJ file with something like ...
<Compile Include="CoreConsoleAppInitializeTerminate.cs" />
<Compile Include="CoreConsoleCommands.cs" />
<Compile Include="..\CADblokeFindReplace\Replacer\*.*">
<Link>Replacer\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
<Compile Include="..\CADblokeFindReplace\Searcher\*.*">
<Link>Searcher\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
I think including all your code and then excluding things that break a specific build it is probably the most maintainable way to go, you can't just keep manually adding a class to each project as you go...
<Compile Include="...\Src\**\*.cs" Exclude="AssemblyInfo.cs;**\Temp*.cs" /> <!-- *.* or *.cs ... you decide -->
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
Code that is specific to a Build Version just goes directly into that project, everything else is added to the master Source project. The upside of this is you can see all of the syntax, intellisense and mistakes (
oh, is that just me?) in Visual Studio. You can unload them if you are sick of looking at them.
Ultimately my goal, and for Andrey too, I believe, is to build plugins for many different applications with the same source code, and to reliably test that code against those different applications.
It must be
- easy to use and
- easy to maintain.
Currently my solution is neither.
Darn.