Shining some light at the “dll hell”

Some time ago I have typed up an article explaining the “dll hell” in Revit/Dynamo. Link I have also typed up an article attempting to deal with it using embedded resources and Cody Fostura package. Link Of course that was a failed attempt because as I found out later, Fody still checked the Global Assembly Cache (GAC) and the current App Domain for the Dll in question before loading it in from the Resources. That was causing potential conflicts.

Perhaps I was misusing the tool, or didn’t know how to configure it at the time. I don’t know. In the comments though, Steve Faust asked a very good question. If Fody was able to rename the assembly to HOK.Newtonsoft.Json.dll, wouldn’t that solve the issue? Yes, indeed (to an extent), but Fody wasn’t doing it. What if we did that ourselves?

The solution

If you are dealing with a 3rd party assembly that is Open Source, and you can rebuild it from source (and license allows you to), then you are in luck here. The idea is that we can download that repo, build it under a different name, sign it with our own Strong Name Key, and then post up to Nuget. Then our application will think it’s a different assembly, and it should stop conflicting with these other assemblies. Let’s do that. As an example I will use Bimbeats and the RestSharp library.

Step 1: Get the repo

Rest Sharp source code is available here: Link You can fork it to your own account. Please make sure to uncheck the “Copy the dev branch only” checkbox. You want the whole repo. I will explain why a little later.

Once you have the fork, you can clone that repo to your local drive so you can open it up in Visual Studio.

Now you can navigate into that repo, and checkout the branch that interests you. Here’s why I wanted to make sure that we download the whole repo in the previous step. I wanted to build my own version of RestSharp, but I also wanted a specific version of it. In GitHub under Tags you can see all of the different versions that RestSharp published over the years. 106.11.7 was one that I was interested in. That older version would not be available if you didn’t fork the whole repo. Just FYI.

Now that you know the version that you want to build, we can check that tag out by calling this command.

Step 2: Build your Nuget

For this particular repository, you will need to install the latest Visual Studio 2022. That’s because this repo is being built against NET5, NET6 and netstandard2.0. Some of these .NET versions were not yet available in older Visual Studio builds like 2019. NET6 I think has been discontinued, so you would have to make sure to select it from the list when installing VS2022. Once you have that installed, pop it open.

You want to change the signing key used to strong name the assembly. The reason you want to use your own here is because if you build the assembly and sign it with the same key, it won’t matter as the application will still think that it’s the same assembly. Strong Name Key and assembly version number is how you identify them to be unique. How do we get our own SN Key? You can go to Visual Studio Command Promp and just type in “sn -k myKeyName.snk”.

Once you have it just set the Strong Naming section of the RestSharp Properties to it.

You can change the name of the assembly or target frameworks.

You also want to make sure that you build the Nuget Package when building the project in VS. Make sure that the Package Id is unique. Nuget already contains a package called RestSharp, so add a prefix to it or something.

Set the package version.

Set the description to let folks know that this is not some official RestSharp package.

When all of the above is done, you can build it. Then go to the bin\Release\ folder and collect your package.

Step 3: Post your package to Nuget

Go to Nuget website and upload your package. Link. You might have to create an account.

As you can see above, someone already downloaded it 32 times. The point of this write up is to build an aliased version of the RestSharp library to avoid conflicts so DO NOT USE this version of it as the only conflict you will avoid is with Revit or Dynamo libraries that use RestSharp, but if you happen to have Bimbeats installed it would still potentially conflict with our custom build. Duh! Hopefully those 32 people know what they are doing and they are not Bimbeats customers.

Conclusion

So yeah, it turns out that there is a way to avoid these conflicts, at least for some of the packages out there that are Open Source, and are licensed in a way that doesn’t impede your ability to distribute them. In this case my understanding is that Apache License 2.0 allows RestSharp code to be used in the above manner. I think the same can be said for Newtonsoft.Json and potentially a few other popular libraries.

I just hope these RestSharp guys don’t hate me as the AEC community starts creating copies of their library and distributing it left and right under a different name. Please be kind, and give them their credit. Open Source community is pretty amazing in that regard.

Ps. Huge thanks to Mingbo Peng for showing me how to do this with Newtonsoft.