4

Whats a good approach for white labeling dll and exe with visual studio?

In essence we want to be able to have the name of the dll and exe change based on the client that we are packaging the solution for, e.g.:

Instead of myCompany.exe and myCompany.db.dll, I would like yourComany.exe and yourComany.db.dll or acme.exe and acme.db.dll, etc

Edit:

Currently we are using a straight visual studio build process with a wix project to create an msi.

Phil Carson
  • 884
  • 8
  • 18

3 Answers3

3

If the only justification for rebuilding it is to change the name, can you just use something generic in the first place? Imagine having to patch 50 identical DLLs, and build/deploying each one separately because they all must be named different things. Even if it's only for a few clients, I would hate to have to maintain that. Versioning could be a hassle too.

If you must do it, I would probably go with a build task (which can perform fairly advanced operations). You mention that you are "packaged the solution"; the viability of a build task would depend on how it is being packaged.

In response to your comment about naming the EXEs with client-specific names... My obvious suggestion there would be to have those applications contain as little code as possible.

The simplest build integration I can think of would be to create a post-build task which ran upon successful compilation in release mode. The task could then read a config file which defined the unique names, and copy the successfully built EXEs to an output directory.

Some of the operations can be accomplished just from the task config file: http://msdn.microsoft.com/en-us/library/ms171466.

Alternatively, you might want to create a little application to do all the work for you, and just pass config switches to it.

For example, here is a little post-build command that I execute to minify my JavaScript/CSS upon successful build of a web application. The concept is similar:

  • build
  • execute an app (like msbuild.exe, or your custom build app)
  • pass data to the executable (like paths, switches, etc.)
  • executable writes the files out
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe

"$(ProjectDir)Properties\build\minify.xml" 

/p:SourceLocation="$(ProjectDir)client" 

/p:CssOutputFile="$(ProjectDir)client\final\final-full.css" 

/p:JavaScriptOutputDirectory="$(ProjectDir)client\final"
Tim M.
  • 53,671
  • 14
  • 120
  • 163
  • You make a good point on the generic naming but at least the exe will have to be named ( and there are several of them ). Have you got an example of how to do this as a build task? – Phil Carson Aug 10 '12 at 02:08
  • Currently we are using a straight visual studio build process with a wix project to create an msi. – Phil Carson Aug 10 '12 at 02:11
  • See my updated answer. You could probably create a custom app to execute during release builds. The app might need to perform subsequent steps (like altering the Wix config) to create a unique MSI for each one. – Tim M. Aug 10 '12 at 02:20
1

You could use ILMerge in whatever post-build process you want on all your outputted assemblies (dll and exe), to create one-off customer-branded builds.

ilmerge /out:CustomerName.exe internalName.dll internalName.exe
Mike Atlas
  • 8,193
  • 4
  • 46
  • 62
0

I don't know that there is a good way to do this without actually building the project as XYZ company. You could try something like this which will give you the desired result BUT it will change the physical name of the assembly as well which may cause dependency problems.

Community
  • 1
  • 1
dparsons
  • 2,812
  • 5
  • 28
  • 44