0

We have one master project that creates a single DLL with FEATURE_1, FEATURE_2 and FEATURE_3 as three conditional compilation symbols that enable those respective features.

MyLib.dll => has FEATURE_1, FEATURE_2 and FEATURE_3 compiled in

We now wish to have the same master project spit out 3 different DLLs as follows:

MyLib.1.dll => has only FEATURE_1 compiled in
MyLib.2.dll => has only FEATURE_2 compiled in
MyLib.3.dll => has only FEATURE_3 compiled in

At present we build within VS2013 and those compile constants are defined inside the .csproj file (within the <DefineConstants> </DefineConstants> tags), which hard-codes them.

Is it possible to pass them via a command line so we can still maintain one master csproj but build the 3 different flavors in the RELEASE configuration just by changing the command line (eg: gcc's -D<buildFlag> style) ? The solution has other projects and they're designed to work with the RELEASE configuration. I'm also open to any other technique that is easy to use and maintain.

We're really trying to avoid creating pseudo-projects or affecting other projects in the solution (21 projects in the solution) - seems like an overkill/hackish for something very simple.

Charles
  • 50,943
  • 13
  • 104
  • 142
DeepSpace101
  • 13,110
  • 9
  • 77
  • 127
  • Please [look at this answer](http://stackoverflow.com/questions/10086591/create-multiple-versions-of-a-project-in-visual-studio-using-build-configuration/10086766#10086766). Probably it is what you need – Steve Apr 10 '14 at 22:38
  • Not sure about that. I need all three DLLs built in RELEASE configuration instead of having three RELEASE-1/2/3 configurations (the other projects in this solution all depend on RELEASE) – DeepSpace101 Apr 10 '14 at 22:40
  • I see, directly from VS you need to define the 3 configuration and run the compile 3 times. Perhaps some wizard with MSBUILD could help you – Steve Apr 10 '14 at 22:42
  • But if you prepare a configuration called RELEASE_FEATURE1 inheriting from RELEASE and apply it to all your projects, then go on every project that require the define FEATURE_1 and set it, finally build the whole solution. At the end you will have in a subfolder called BIN\RELEASE_FEATURE1 your app with only this feature enabled. Repeat for the other two and you have 3 different set of assembly in their respective subfolders. Fron now on you just switch the configuration and you rebuild the required set – Steve Apr 10 '14 at 22:49
  • Of course, as long as you build from the command line. Doing it from the IDE requires adding solution platforms. This is a dreadful hack that invariably is solved better by using a config file. C# doesn't give you the same hassle as GCC does to create one, not in least thanks to the just-in-time compiler. Use Project + Properties, Settings. – Hans Passant Apr 10 '14 at 23:22
  • @HansPassant: New to that; how will a runtime config item featurize the MyLib.1.dll? Also the .config lives in plain text, so anyone can simply "refeaturize" it. Lastly, IIRC, this wouldn't trim external DLL dependencies (e.g. removing FEATURE_1 means I can also remove Feature1.Helper.Dll, and so on). Maybe I should back up and ask how featurization is done in C# ... was expecting a simple fix but the comments and answers indicate this might be non-trivial :( – DeepSpace101 Apr 10 '14 at 23:46

2 Answers2

0

I haven't done anything with the command line, but to solve similar problems, I created separate projects (that define the Framework Target and any conditional compilation symbols), and then add all the project files as LINKED files. In this way, I only have to modify a single set of source files, but each project compiles into its own DLL.

To add a file to a project as a linked

  1. Right click the project and click Add Existing Item...
  2. Select the file (or files) you want to Add.
  3. Instead Of clicking the Add button, click the arrow next to the Add button, and click Add as Link.

I'm not sure if this will work for your case, but it sure has saved me lots of time when developing libraries for different .NET framework versions.

Nathan A
  • 11,059
  • 4
  • 47
  • 63
  • Thanks but that still makes us bear the burden of manually maintaining coherence across multiple projects e.g. add a file `new.cs` to the "main" project and you must now remember to add links to `new.cs` into the other 'linked' projects. It's worse if you have resources with specific project properties (been there!). Overkill to replicate an entire project (even linked) just to specify a single build flag! – DeepSpace101 Apr 10 '14 at 22:55
0

Is it possible that you have a complete turnaround?

Instead of defining all features in a single library and then disable some of them, you can create individual projects for each features, and then at packaging phase merge the smaller assemblies into a single one.

Microsoft has ILMerge, while ILRepack is an open source alternative,

https://www.nuget.org/packages/ilmerge

https://www.nuget.org/packages/ILRepack/

Then you are free of conditional compilation, which is too difficult to manage, and the complexity is moved to your packaging scripts, which can be easily managed and checked into source code management.

Lex Li
  • 60,503
  • 9
  • 116
  • 147