Deploy assembly as part of .Net Framework

Question

I have an assembly (MYASM.dll) targeting .NETFramework 4.0 (with a strong name)

I want to deploy this assembly in a way it is part of .NETFramework (or the whole system thinks it is) on target machine.

By that I mean:

.NET runtime sees it at it sees System.dll (no need to deploy locally or provide a reference path)
MSBuild sees it when I do <Reference Include="MYASM" /> without needing a hintpath
User is able to make Add reference in Visual Studio and that introduces <Reference Include="MYASM" /> without the strong/full name

I have solved 1. (and apparently 2.) by adding it to the GAC. But this is apparently not sufficient.

I have partially solved 3. by putting my assembly in a special folder ([INSTALLFOLDER]\lib) and set registryKey HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0\AssemblyFoldersEx\MyAssemblies

Then I can do Add reference, but then I get:
<Reference Include="MYASM, Version=1.1, Culture=neutral, ..." /> in my csproj instead of just <Reference Include="MYASM" /> as I'd like.

With the second approach, if I manually edit the csproj, everything is OK, but I can't ask my users to do that.

What should I do here?

[EDIT] apparently it’s not obvious I have my own MSI. But yes I have. I don’t control users machines with a magic wand

1st, you can't just put your assembly to .net framework. You need a your own installer, which will put it in GAC on every client machine. 2nd, what you see here `` is a strong name, so if your assembly is strong-named, that is how you should add a refference. — vasily.sib, Jul 10 '18 at 07:49
I have a custom installer to put assemblies in the GAC. When I remove the strong name, I still have the same issue about — Regis Portalez, Jul 10 '18 at 11:56
You may try this https://community.flexerasoftware.com/showthread.php?199027-How-to-register-a-Net-Com-Assembly — Vijay Kumbhoje, Jul 10 '18 at 12:54
Please you guys make an answer, so my rep is not lost for everyone — Regis Portalez, Jul 10 '18 at 17:15
can you then please explain why do you need to deploy your assembly separated from your app? — vasily.sib, Jul 11 '18 at 03:01
Because it will be referenced by my own app, an potentially many users app. But both are deployed by the same msi. — Regis Portalez, Jul 11 '18 at 05:39

score 5 · Accepted Answer · answered Jul 11 '18 at 12:10

No, you've taken this as far as it can go. It isn't actually that obvious how VS figures out to put the partial assembly name into the project file. This is not public code and can't be tampered with. Pretty sure it does not use a white-list and it can't pay attention to the reference assembly location.

Most likely detail is the PublicKeyToken of the assembly. The framework assemblies always have to exact same value for them, b77a5c561934e089. Its value is even prescribed in the CLI spec (Ecma-335). Next most likely by a considerable distance is the signing certificate, identifying the assembly as owned by Microsoft. Both however present the exact same problem, you can't get the private key that is required to strong-name or sign the assembly. They are locked inside a vault in Redmond, only trusted build engineers have access to them.

There is another nasty little detail you are overlooking, you are not nearly scared enough of DLL Hell. Cold hard fact is that if you ever expose the assembly in the GAC on another machine that is not in your control then you can never change it again. You can no longer modify the public interface of the assembly. Can't add a new public method or type, can't modify the arguments and return type of a method, can't add an enum member, etc. Even harsher, something Microsoft worries about, is that you can't really change private and internal members either. Programmers have a knack for using Reflection to poke around, terrific bug fixing tool. But at least you can tell them "don't do that!".

Making such modification requires increasing the [AssemblyVersion]. Now you get a different kind of DLL Hell, the machine might not have been updated by your installer. Or worse, a solution uses projects that have different references. Microsoft had to solve this problem for framework assemblies, they did so by modifying the CLR. Automatically forwarding old versions to new ones. The basic reason why using an assembly built for .NET 2.0 can be used in a .NET 4.x project. You can't get that kind of service for your own DLL.

"Don't do it" is the only good advice, getting in DLL Hell trouble is however a terrific learning experience I can recommend for anybody. Hell has to be experienced to be feared.

Best advice is to publish a Nuget package. They do the exact opposite, never deployed in the GAC and version numbers change very rapidly. But always available when a programmer needs it.

Well thanks. b77a5c561934e089 is the key :) I guess I'll drop GAC and the add reference stuff :) — Regis Portalez, Jul 11 '18 at 12:35

score 1 · Answer 2 · answered Jul 11 '18 at 12:18

There are a few ways...

1) is to create a new setup and package this for the framework you target. You can Package this and have it deployed using the domain controller. When your users log in the domain will update the packages, this way you'll be able to deploy your software to specific users and or user groups. Depending on your infrastructure you'll have a software management infrastructure that you can use (2 links included).

2) Create a NuGet package if you're targeting developers. If your organisation host your own NuGet server limiting the distribution. Add the Package source to Visual studio open the Options Page, type NuGet in the search field and set the URL/ UNC path.

3) use OneClick deployment, this allows you to have the application download the updated dll's and install them on the machine. It requires a Code Sign certificate but you're probably signing your code anyway (better for Anti-Virus tools if you do).

Now linking your MyAsam.dll will be done by the application linking definition or IoC container. Basically, if it finds the dll and no version is defined it will take the first one it finds I think the order is 1 AppFolder, 2 GAC, 3 Path, not sure. This "take what you find" is generally referred to as "DLL-Hell", The NuGet and OneClick solution works best in this as You will always get the Updated dll that works for the application. Placing the DLL in GAC is going to get problematic if you have moe than 1 application using your dll and both need the "right" version where the "right version" differes between them....

score -1 · Answer 3 · answered Jul 11 '18 at 09:15

-1

If you have the source code available for MYASM.dll, then I would prefer adding a project reference to your consuming application. When doing so, Visual Studio shall create a GUID for all the referenced project.

answered Jul 11 '18 at 09:15

Manoj Kapoor

69
1
7

I can't do that on a user's machine. – Regis Portalez Jul 11 '18 at 09:28
How about creating a Nuget package for the assembly, every time they build the solution it will automatically download the updated package? – Manoj Kapoor Jul 11 '18 at 11:48

Deploy assembly as part of .Net Framework

3 Answers3