Unexplained "Strongly-Named Assembly Required" Error In Revit Add-in

[DJB_CADfx]

We have a Revit add-in we've created for a customer that uses API updaters to track changes to specific Sheet Parameters as well as when a new sheet is added. The changes captured by these updaters are stored in Extensible Storage in a single string of JSON data. 

We have a random (a few times a week) error that occurs when the new sheet updater fires. When it happens, the user receives the error message:

"A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)"

The user then receives an error message from Revit stating: 

"Third party updater "New Sheet Updater" has experienced a problem and its action had to be canceled."

this message allows the user to either Cancel or choose to Disable Updater. If they Cancel, it will continue to happen each time the user attempts to add a sheet in that session. If the user chooses Disable Updater, then they can add the sheet in that session. However, if they close Revit and go back in, it will work fine so it isn't easily repeatable other than once it happens, it continues for that session of Revit.

This is a very perplexing problem with both its randomness and the fact that neither Revit, nor any of its add-ins (including ours) are strongly-named. Does anyone have any clue what could be happening to cause such an error?

The code running at the point when the error occurs is performing the following:

1. Obtain our Extensible Storage object and deserialize the JSON data within it
2. Add the new sheet to the deserialized JSON data
3. Re-serialize the JSON data and write back into same Extensible Storage object

[arnostlobel]

I may be wrong, but just from the description of it I have a feeling that the problem may be not with Revit. Naturally, it is hard to state anything without actually seeing the error message and debugging the execution when the exception happens, but my assumption is based on the fact that Revit does, apparently, invoke the updater (i.e. its Execute method) without throwing an exception. Later, Revit shows a warning informing the end user that the Updater failed, but it is most likely only because the updater somehow caused an exception to happen and did not catch it. Again, this is just my guess, and I would be curious to see results from debugging the case.

I understand that it is hard or even impossible to debug because of the sporadic nature of the failures. However, I assume it ought to be possible to add some debugging code to the updater to help narrowing possible places at which the exception (the one about strong naming) could happen. I suggest adding as many throw-catch blocks into the updater as possible. At each catch block the updater could show a message (or log it into some log file) and then re-throw the exception. With enough luck we could learn what part of the code is involved.

By the way, what version of Revit do you use?

Arno?t

[DJB_CADfx]

This tool is used for Revit 2013 - 2016 depending on the project (the customer has projects that may last multiple years and sometimes they are required to remain at a particular version of Revit for the life of the project).

Looking at what little code is actually running at this time, we narrowed our suspects down to the JsonConvert.DeserializeObject() line of code as this is the only piece of code that would cause the loading of another assembly. Using Process Explorer we looked at the assemblies loaded under Revit on a system not exhibiting the problem vs. one that does have the problem and found that the Newtonsoft.Json.dll assembly was loading from 2 different locations.

On machines with the problem, the assembly is loading from C:\Program Files\Dynamo 0.8\Newtonsoft.Json.dll and this is an older version of that assembly than the one that is loaded on machines that do not have the error. I don't know anything about Dynamo or what some users are doing to cause it to load the Newtonsoft.Json.dll assembly from the Dynamo location, but that is what we are investigating at this point.

If this new information sparks any new thoughts about what might be happening please let us know. In the meantime we will continue our investigation to verify for certain whether this is the cause of the problem or just a coincidence.

Thanks,

Dave Blackburn

[DJB_CADfx · Accepted solution]

Well, that didn't take long. We have verified that if the older Newtonsoft.Json.dll assembly is loaded, it causes this error. Doesn't seem like the correct error message since none of them are strongly named, but whatever.

We'll have to either force it to load the correct one via code (which I haven't ever tried figuring out) or bundle the correct version into our add-in which we have done before without too much work.

Thanks,

Dave Blackburn

[DJB_CADfx]

It turns out it is incredibly easy to ensure that the correct version of the assembly is used. Probably most programmers already knew this, but I had never had the need up to this point... If there is anyone else who doesn't know: In the properties for the reference in your project just set the Specific Version property to True. Then make sure you include the correct dll along with your add-in and it loads that one.

[arnostlobel]

I am happy you've figured it all out.

[DJB_CADfx · Accepted solution]

Just one final point to make for those who happen to read this in the future. We decided to go with the bundling route (using ILMerge) instead to ensure that we didn't break any other applications that were relying on a version of the refernced assembly that is different from our own.

Normally for bundling of references we have used Costura.Fody which is an incredibly simple solution. However, we found it does not work well with this particular case. It does not distinguish between versions of the same assembly, so if the required assembly was already loaded by another application it uses it regardless of the version of that assembly. ILMerge will use the bundled instance of the assembly ensuring that your app uses the correct version.

Regards,

Dave Blackburn

[devonpowell]

it took me half a day to find this post. I found this stackoverflow question but it seemed complicated for a newer programmer. Thanks for the simple solution.

[awmcc90VZTT2]

I'm currently having this issues and none of the solutions I have attempted have worked. How did you use ILMerge to create the embedded solution for you? Did you use the command line or did you use a nuget package? I'm really stuck on this. I've also tried hooking straight to the dll and loading it as an embedded resource and loading it by it's path and still can't get anything to work. 

Anyone have any more insight on this?

[DJB_CADfx]

We just added a Post-build event command line in the settings for the project similar to this (this places the newly bundled version of the addin in a sub-folder named "Bundle" in the TargetDir of the project :

c:\<path to ilmerge.exe> /lib:C:\<path to folder containing add-in & Newtonsoft.Json.dll> /lib:C:\<path to folder containing RevitAPI libraries> /t:library /out:$(TargetDir)Bundle\<Name of your addin>.dll <New name for bundled addin>.dll Newtonsoft.Json.dll

Note: This solution did not work for Revit 2014 and earlier, only 2015 & later. We never found a solution that worked for 2014, but it was decided that 2015 & newer was sufficient for our needs.

[Anonymous]

Revit sometimes throws some strange error messages.

Also about the loading problem of different versions or loading failure, I think we can consider using:

Assembly.LoadFrom(Assembly.GetExecutingAssembly().GetFilePath('xxx.dll'));

Sometimes Revit makes silly mistakes, which can be solved by means of this patch. Of course it looks a bit weird, when the program is not reporting errors, you can delete it.