Note to myself for future for this issue: After making some changes to an application, I went to publish it using Visual Studio, as a ClickOnce application. On trying to install the resulting published application I got presented with the following error.
Unable to install or run the application. The application requires that assembly Newtonsoft.Json Version 18.104.22.168 be installed in the Global Assembly Cache (GAC) first.
I searched for any reference, or mention of the NewtonSoft 6 version but found nothing, anywhere in any projects involved. There was a old folder in the NUGET cache for it, so it had been in use at some point.
Totally stumped, the breakthrough came when looking at the build log. There were warnings in there about the version of Newtonsoft.
Ah – that makes more sense, so I added a mapping into the app.config.
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-22.214.171.124" newVersion="10.0.0.0"/>
After publishing the application launched correctly again.
There must be some 3rd party dependency somewhere that is looking to the old version but I can’t track it down. Remember ClickOnce applications run in a sandbox.
** If you found this useful, drop me a comment to let me know, as it motivates me to blog more!
In Dynamics GP development, we have lots of .dll files around arising from support for many version releases of GP. These files litter our projects and sometimes a dll may go astray and cause trouble by ending up in a folder to which it should not belong.
This powershell command is a quick way to look for all the versions of a .NET assembly (dll) version within a folder tree.
Get-ChildItem -Filter Microsoft.Dexterity.Bridge.dll -Recurse | Select-Object -ExpandProperty VersionInfo | Out-String -Width 180
ref: Stackoverflow Get file version and assembly version of DLL files in the current directory and all sub directories
The versions can be seen on the left and any offending .dll files that are not in the correct directory for their actual version number can be quickly and easily identified.
This avoids getting into <assemblyBinding> redirects when dealing with the error at compile time of
Found conflicts between different versions of the same dependent assembly
It seems you need to install the C++ developer options when installing (or repairing) Visual Studio, for the image editor, icon editor, resource editor to become available.
Moving from developing ASP.NET sites against the full IIS to IIS Express led me to migrating the many virtual directories that were defined for the site. There was an added dimension to the problem, in that the the virtual directories map to central development resources server to keep the many GB of images and tens of thousands of pdf files off the developer SSD drives, for space reasons (and sanity).
To my relief it turns out to be totally possible for website projects (as oppose to website application projects), but I didn’t on performing a quick internet search, find any reference to credentials.
The virtual directories can be set up as part of the site definition in the .vs folder within the applicationhost.config of the website solution. By editing that file, under the following node:
<application path= …
<virtualDirectory path= …
Luckily rather than in notepad, I opened up this file in Visual Studio, and found intellisense gave me the answer I had been looking for, and it was a good one!
You can see there are userName and password attributes available.
So add a virtualDirectory node for each virtual directory, following this pattern, one after another, after the application node.
<virtualDirectory path="/imageitems" physicalPath="\\resServer\Resources\ProdRes"
userName="firstname.lastname@example.org" password="ourpassword123" />
We use a read only, low rights user for this, so I’m not too bothered about the password getting into the config file.