Page 1 of 1

Support for importing different versions of the same assembly

Posted: Tue Nov 20, 2018 10:15 am
by whiggs2
Product, version and build: Powershell studio version 5.5.155
32 or 64 bit version of product: 64-bit
Operating system: Windows 10 1803
32 or 64 bit OS: 64-bit

Powershell studio needs to be able to import different versions of the same assembly via the assemblies feature, as there are times when this is necessary. For example, in order to use the box .net assemblies, both Newtonsoft.json 10.0.0.1 and Newtonsoft.json 9.0.1 are needed in order for it to work. The reason is best described by a box employee I spoke to:
the Box SDK depends on Newtonsoft.Json 10 but the System.IdentityModel.Tokens.Jwt library we use depends on 9. A full .NET project respects the SDK's app.config file that does a binding redirect to reconcile these dependencies, but if you're loading assemblies manually in PowerShell you're probably not picking that config up and the IdentityModel library is not able to resolve it's dependency on Newtonsoft.Json 9.
This being the case, it would be awesome if powershell studio would allow this functionality when selecting assemblies to import.

Re: Support for importing different versions of the same assembly

Posted: Tue Nov 20, 2018 11:02 am
by davidc
This is a .NET issue that is created by a third party when they don't keep their assemblies in sync (in other words assembly hell).
You need to redirect the assembly version to the newer version using a config file and you can accomplish this by packaging the script into an executable and updating the generated config file.

Note: .NET will only allow you to load a single version of an assembly. This is why you need to redirect the older version to the new version.

Re: Support for importing different versions of the same assembly

Posted: Thu Nov 29, 2018 12:17 pm
by whiggs2
Yes sir. Fully aware of that. I included that information in my original post. But since the packaged scripts that most everybody makes are portable, this creates a scenario where the app.config file would need to travel with the packaged script at all times for it to work, which is just not going to happen. This is now the second time I have submitted this issue, and it is not like it cannot be done. It actually can be done, as, since Sapien decided to ignore my request for this the first time I asked, I have been just writing out the code within the scripts to import both versions of the assembly within the script itself:
Image
I like to think that I know what I am talking about and do not request things frivolously, so, rather than making an unreasonable recommendation that would require that people keep an "app.config" file in the directory as the packaged executable (what if there are more than one packaged scripts in a directory? Your recommendation would require each script would need to have its own folder. It just not possible and is extremely limiting.), how about a simple "what a good idea. We could improve our product tremendously by implementing this. Thank you for your input. We will get right on that." It would be so much appreciated rather than having to fight tooth and nail to help you guys improve your product.

Re: Support for importing different versions of the same assembly

Posted: Thu Nov 29, 2018 2:31 pm
by Alexander Riedel
We did not invent config files. It is Microsoft's prescribed mechanism for addressing issues like that.
I would suggest you contact them to air your misgivings about the danger of executable and config file becoming separated.
As you seem to have code to address the issue without the config file, you can just make it a snippet and use it where needed.
I am not sure what else we could provide here, seeing that you already have two workable solutions to your rather unique problem.