We Keep Coding

Build project twice with different DefineConstants

As part of a bigger solution I'm writing a wrapper for a third party tool. We need to support two different versions of that tool, depending on which version is already installd on the end user's machine. The versions are similar, bug some APIs have changed.
I have a wrapper project that can do the right thing depending on some DefineConstants, say TOOL_VERSION_1 and TOOL_VERSION_2.
Is there a way to automaically build the wrapper project twice when I build the solution? Each of the builds should of cause use one of the DefineConstants and should output to a different file, say "Wrapper.V1.dll" and "Wrapper.V2.dll". Idealy the solution should scale for 3 or more versions.
I'm hoping for something simple like with target frameworks where you can just give a list of frameworks in the .csproj file and the SDK will build each one in turn. I was looking into custom build targets but that hasn't been very productive so far.
I only just leared about shared projects and they should able to solve my problem. However as I have several projects that all need to be treated like this I'd rather have a solution that doesn't require me to tripple the number of projects.

C# Project with either ProjectReference or Reference

we are working on many different applications where each application has its own VS solution (and of course a CS project). Additionally there are many libraries (also CS projects) that are shared between the applications and are included in the VS solution so that you can debug during startup phase of the development.
We also have a "master" solution that contains all projects in one big solution for refactoring issues. Because VS does not support "solutions in solutions" we have to maintain also this master solution. We are talking about 300 assemblies.
Now a point is reached where it's helpful anymore to have all CS projects as ProjectReference in the application solution anymore. For example we have a library that does the CUDA support which can be compiled once and then used as a regular Reference.
The only problem here is that there are occasions where you need the ProjectReference back again when you need to debug into a problem that can only be verified when it runs in conjunction with the main application and cannot be verified in a normal test case.
One option would be to maintain two projects, one for debugging and one for working. The only problem is that once you debug and you need to use the ProjectReference the dependencies cascade down the whole project tree.
For me it feels like that I need two CS projects for each project. One that only contains References and another one that only contains ProjectReferences. Mixing could be a problem. The question is, if there is something automatic where a Referency-only project can be created from a ProjectReference-only project?
How do you solve something like this?

CNTK.GPU conflicts with CNTK.CpuEval-mkl

I was previously using the NuGet package Microsoft.Research.CNTK.CpuEval-mkl to evaluate some models, until I ran into problems with CPU speed. At that point I switched over to the CNTK.GPU library.
Unfortunately, I noticed a marked decrease in the efficacy of my models, so I suspect that I did something wrong. Just to compare, I would like to run both versions within a single application, have it output the raw evaluation results of each and compare them.
Sadly, when building I get messages about missing DLLs. Which ones are missing depend on which NuGet package was added first. If I add the GPU one first, I get the following list:
- Cntk.Core-2.0rc1.dll
- cudart64_80.dll
- curand64_80.dll
- cusparse64_80.dll
- cudnn64_5.dll
- cublas64_80.dll
- Cntk.Core.CSBinding-2.0rc1.dll
- nvml.dll
If I add the CPU version first, then only one DLL is missing:
- Ctnk.Eval-2.0rc1.dll
Is there a way to force the two to work together, or do I need to run two separate applications and manually compare the output?

It is not a supported scenario to install both Nuget pacages to the same application. You might get it work with manually adding references to your project, but we have never tried and tested this.
Thanks,

Versioning software without having to edit lots of config files

We have a project that uses a couple of assemblies.
Is there an easy way of handling the version of all those assemblies at once?
We have a version like
major.minor.patch.revision
Most of the times on a release, just the minor version gets a change.
A critical part is the revision which is the fileversion in the repository.
At the moment I think this makes impossible to use one AssemblyInfo.cs for all assemblies.
How can I avoid to change the AssemblyInfo.cs of all those assemblies?

If you want all of the assemblies to have the same version, you can make a single .cs file for the versioning in one of your libraries, and add it as a link to the other projects.
This will cause the single file to be part of all three assemblies, and keep the version constant across them all.

I've found that this is easiest to do when you're going to create your build artifacts. From a process standpoint, you would:
1. Tag/Label Source
2. Get by Tag/Label
3. Edit AssemblyInfo files
4. Build, Test, Etc
5. Capture Build Artifact
This is all pretty easy to do in BuildMaster(disclaimer: I work for Inedo as a set of actions. In this case it'd be just using the Write Assembly Versions action after doing a Get Latest action.
You can see this pattern used a lot in the specifics libraries. When we build ProGet, for example, you'll notice that Write Assembly Versions shortly after comparing the directories for changings, and right before running msbuild.

How do you package external libraries in your .Net projects?

A lot of my projects contain the Castle/NHibernate/Rhino-Tools stack. What's confusing about this is that Castle depends on some NHibernate libraries, NHibernate depends on some Castle libraries, and Rhino-Tools depends on both.
I've built all three projects on my machine, but I feel that copying the NHibernate/Castle libraries is a bit redundant since I built Rhino-Tools using the resulting libraries from my NHibernate and Castle builds.
Right now, I include all projects in seperate folders in my /thirdparty/libs folder in my project tree. Should I simply just have /thirdparty/libs/rhino-tools in my project and use the Castle/NHibernate libs from there? That would seem to make logical sense in not duplicating files, but I also like having each project in it's own distinct folder.
What are your views on this?

This is one of the problems that we're trying to tackle in the Refix open source project on CodePlex.
The idea is that Refix will parse all the projects in your solution, and before your project compiles, copy the necessary binaries from a single local repository on your machine into a folder within the solution tree and point the projects at them. This way, there's no need to commit the binaries. Your local Refix repository will pull binaries from a remote one (we're setting one up at repo.refixcentral.com), and you can set up an intermediate one for your team/department/company that can hold any additional software not held centrally.
It will also try to resolve conflicting version numbers - Visual Studio can be too forgiving of mismatched component version numbers, leading to solutions that compile but fall over at run time when they fail to load a dependency because two different versions would be needed.
So to answer the question "how do you package external libraries in your .Net projects", our vision is that you don't - you just include a Refix step in your build script, and let it worry about it for you.

I use a folder for each, which seems to be the convention.
Does it really make a difference if you're copying them?
What if you want to switch one out? Let's say you go with a new O/R mapper. It will be much easier to just delete the NHibernate folder than to selectively delete DLLs in your Rhino-Tools folder.
Take this to it's logical conclusion and you won't have any folder organization in your lib folder since everything uses log4net :)

Add additional probing paths to your app.config files to locate the dependency dlls. This way your can get away with having just one copy of everything you want. Though there are some quirks to using this feature (you must create the folder structure in a certain way). Look here for more details on the tag.

I will definetly recommend having a thirdparty or vendor folder in each of your project trees. If you find it annoying to have 32 copies of the rhino-tools package, you can have a single copy of it in your code repository, and do external references to it in your project tree.
Lets say you are using SVN, you can make a repository called "thirdparty libs" and in this have versioned copies of the libs. You then make an external property on your "thirdparty"-folder in your project tree which then in turn automaticly will do a check out of your centralized thirdparty libs. This way you for instance only have to update in one place if a security or a bugfix comes out, but each project is still in command of choosing which thirdparty libs, and which versions to use.
About the deps internally in thirdparty libs, i wouldn't mind those. The first time you compile your project, and some of the libs arent copied to your bin-folder because of implicit dependencies you can add an external attribute into your bin-folder, which will then automaticly check out the missing libs. That way you still only have to update your thirdparty libs in one place.