1

So I'm adding a "d" extension to my assembly name when building in debug mode. As far as I can tell the standard way to do this in C# is to edit the .csproj file and put in the following:

<PropertyGroup>
  <AssemblyName Condition="'$(Configuration)' == 'V90 Debug'">$(AssemblyName)d</AssemblyName>
</PropertyGroup>

That has the desired effect, but now the darn project always rebuilds the output .dll, causing other projects that depend on it to relink, etc.. Without this change, I don't have any such problem.

So far increasing the verbosity of the project output hasn't helped.

Edit: An additional, important detail is that we're using names like "V90 Release", "V90 Debug", "V100 Release" etc.. for our configurations, so that we can target different versions of the Visual Studio runtime. I wrote a test app with the standard configuration names and found my problem doesn't happen in that case.

Nathan Monteleone
  • 5,430
  • 29
  • 43
  • 3
    Why are you doing something so non-standard? (there is no "standard" way to do what you are doing). – Oded Aug 02 '11 at 19:13
  • Well, standard in the sense that it's the accepted answer here on StackOverflow: http://stackoverflow.com/questions/2855629/c-vs-net-change-name-of-exe-depending-on-conditional-compilation-symbol. I'm doing it this way because it allows debug and release dll's to coexist in the same directory without naming clashes. – Nathan Monteleone Aug 02 '11 at 19:15
  • 2
    @Nathan Why would you want them to exist in the same directory? It's *very* standard to have Debug\Release\Whatever directories. – Tim Lloyd Aug 02 '11 at 19:17
  • It's also pretty standard to add extensions indicating the configuration. boost, Open Scene Graph, and others do it. We chose that scheme quite a long time ago and are just now starting to use C# on our project. – Nathan Monteleone Aug 02 '11 at 19:24
  • 3
    @Nathan I disagree. Whilst you may have found some examples of it, it is certainly not "standard". There are probably all sorts of things that will not play well with this. That's my 2 cents anyhoo. Are there real compelling reasons to do it? – Tim Lloyd Aug 02 '11 at 19:30
  • @chibacity - that does seem to be the case... Visual Studio certainly doesn't seem to like it. I'll leave the question open in case someone happens to know a workaround. – Nathan Monteleone Aug 02 '11 at 19:32
  • "we're using names like "V90 Release", "V90 Debug", "V100 Release"" That sounds strangely familiar... :-) – James McNellis Aug 18 '11 at 17:19
  • Amazing how these things can come back to haunt us, isn't it? – Nathan Monteleone Aug 18 '11 at 20:11

1 Answers1

4

You are using an old standard in C/C++ development. The Big Difference with managed code is the absence of a linker. You used to configure the linker to use the "d" version of the library in the Debug build, the non-d version of the library in the Release build. That mechanism is completely absent in .NET, code in libraries are dynamically linked at runtime. Making the practically of having different names for different builds dramatically less.

One of the problems you'll encounter if you pursue this old strategy is that you'll have additional problems with the reference assemblies of a project. There is no decent way to use different names in different configurations. Dependent assemblies are listed in the Reference node of the project, this is a property of a project that is not configuration dependent. It is not impossible, you'll need a lot more Condition hacks to rename the reference assemblies. Build dependency checking is likely to be affected by this as well.

This is not actually necessary, the debug and release build of the assemblies will have the same metadata. But if you skip that, you'll now have a problem at runtime. The CLR will be told to use the wrong assembly name. Hacking around that is technically possible by hiding the assemblies in a sub-directory and using the AppDomain.AssemblyResolve event to load the correct one. You'll need a post-build event to rename and copy the assembly into this directory. This all gets ugly in a hurry when those assemblies have dependencies on other assemblies.

Long story short, your previous standard just isn't a good one for managed code.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536