Home/ Questions/Q 848485
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T06:56:58+00:00

I have one solution with a .NET 4.0 project (C#) that produces a delayed

  • 0

I have one solution with a .NET 4.0 project (C#) that produces a delayed signed dll, that I dotfuscate and sign.

EDIT: This is how I version the dll:

[assembly: AssemblyVersion("0.7.0.*")]
[assembly: AssemblyFileVersion("0.7.0.0")]

I have another solution with a .NET 4.0 project (C++/CLI) that references the signed dll and produces a signed dll (actually, delayed signed and signed in a post build because of a flaw in the C++ build system).

The problem is that the reference to the dll contains a specific version number, which includes even the build number (I want to have a build number).

Every time I build the referenced dll, I have to change the project settings file (.vcxproj) so it reference the new version dll. Since I work with source control, this is very inconvenient (different computers might have different build numbers since each computer build its own referenced dll – the referenced dll is not in the source control).

If I don’t change the reference, I get a warning:

warning MSB3245: Could not resolve
this reference. Could not locate the
assembly…

And many errors like this:

error C3083: ‘Foo’: the symbol to the
left of a ‘::’ must be a type

These are resolved once I change the reference.

How do I make the reference ignore the build number or even the entire version number?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The C# IDE has an option for that, “Specific Version = False”. Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you’ve got a potentially breaking change that can make code that has a dependency on those classes fail.

    At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.

    An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.

    Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.

    For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don’t have to delay-sign, only resign with -Ra in a post build event.

    • 0