0

Related to this question here, I am trying to create an installer which installs DLLs on the target user's PC and makes them available to the Visual Studio Reference Manager (Project > Add References)

I have figured out that to make an assembly visible to the .NET4.0 Reference Manager, I need to add this Registry Key

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.0 assembly>

And for .NET4.5, I need this key

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.5.50709\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.5 assembly>

However I now have a problem. When I go to Add-References, I see something like this

enter image description here

So my question is, what is the best practice here for distributing multiple DLLs compiled to different .NET Frameworks (e.g. .NET4.0, .NET4.0 Client Profile, .NET4.5) and targeting different machines (x86, x64, AnyCPU) so that only one version shows up in Add-References OR So that versions can be differentiated in the Add-References dialog?

Community
  • 1
  • 1
Dr. Andrew Burnett-Thompson
  • 20,980
  • 8
  • 88
  • 178

1 Answers1

0

In general the best practice is to not mess with the user's registry. Do note that a programmer won't expect to find a non-Microsoft assembly in the Framework list so might never even look there. The added convenience is fairly minor, the user can simply use the Browse button to pick the reference assembly you copied onto his machine. Albeit that you do need to provide him with a hint on where to look. Not much of a problem when you use the standard c:\program files\company\product naming strategy.

Avoiding the duplicate is otherwise easy. If your assembly is compatible with .NET 4.0 then only modify the v4.0.30319 key. A project that targets 4.5 will include 4.0 assemblies in the list. If you require 4.5 for some reason then modify the v4.5.50709 key.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Yeah I've noticed this - the 4.5 dialog shows both (which is the problem, its impossible to tell which is which). What's best practice here, rename assemblies? E.g. MyAssembly-net40.dll, MyAssembly-net45.dll? Regarding registry, I hear you but this is for a commercial component DLL. Pretty much all component DLLs add something into the registry in order to make their DLLs available from Add References dialog – Dr. Andrew Burnett-Thompson Apr 10 '13 at 11:47
  • I don't understand why you are hemming and hawing over this. Clearly your assembly is 4.0 compatible so only register it in v4.0.30319. There's no point in building a 4.5 specific version, it won't be different if it doesn't reference assemblies that are only available in 4.5. It still targets CLR version 4.0.30319 – Hans Passant Apr 10 '13 at 11:53
  • I see, so you can reference a .NET4.0 assembly in a .NET4.5 application just fine? If so I didn't realise that. No I am not using any specific .NET4.5 code How does this also apply to Client Profile, or x86, x64? There is a genuine need to compile for AnyCPU as well as x86, x64 since the target DLL is often used in mixed managed/native applications – Dr. Andrew Burnett-Thompson Apr 10 '13 at 12:32
  • Hmm, that means that you have a dependency on a bunch of other DLLs as well. That need to be located when the program is run. You cannot hide that fact in a dialog that was only meant to add an assembly reference. There are various techniques to deal with runtime dependencies, rather out of scope for this particular question. Check [this answer](http://stackoverflow.com/a/11936113/17034) for example. – Hans Passant Apr 10 '13 at 13:12