We Keep Coding

Trouble with "Assembly File Selector" Dialog Box

I am getting this error message on one of my development computers:
Assembly File Selector
The following assembly name can not be resolved automatically.
System.XML, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Please select the assembly file manually.
The error is happening on a new computer I just setup. This error does not happen on any of the other computers I have used my program on.
The program uses .NET Framework 4.8. I have installed that framework on this computer. I am both building my program and running it on this computer.
Nothing I do with the dialog box seems to matter. My program works fine if press OK or cancel. Selecting a file does not prevent the dialog from appearing again.
I assume there's some configuration step that didn't happen right on this new computer. What can I do to track down what is going wrong?

That is a very old version of System.Xml - .Net 4.8 would have version number 4.0.0.0. If you are not intended to use an older version of .Net, verify your references are not set to "Use Specific Version" and that your project is targeting .Net 4.8.
That dialog looks like something from Redgate Reflector, which implies you are working with existing assemblies. In that case, you might check the version of the reference in Reflector to confirm.
Do you have the same versions of the older frameworks installed?

I was able to solve the problem thanks to hints from Mitch and Simon Mourier.
My specific application is an add-in for a program called Revit. During development, I use another add-in to load my add-in. I was using an older version of the other add-in. For whatever reason, on this specific computer, it was throwing this error. I am using the same old add-in on other computers with no problems.
I replaced the other add-in with the most recent version and it works correctly.
I looked at the referenced for the old add-in. I referenced the latest version of System.Xml (4.0.0.0). There were no references to System.XML version 1.0.0.0. I never did track down why that was specifically being ask for.

NuGet; Transitive Dependencies; Binding Redirect Hell

.NETCore just litters your disk a lot worse, too many versions, too many assemblies, too many standards and no GAC. Hopefully they'll get their act together sometime soon. – Hans Passant Aug 17 '17 at 10:37
No, it just keeps getting worse.   : \
Have a .NET Standard 2.0 class library that references Microsoft extension classes. When we deploy to the server, we get runtime binding exceptions. My questions first:
Why aren't binding redirects being generated for transitive dependencies?
Since they're not, how do I come up with a full list to add manually?
How does the compiler know what version to redirect to unless it intends for me to deploy the version it compiled against?
How do I come up with a list of DLLs to deploy - excluding framework DLLs but including anything that wouldn't be on the server?
Is a nuget package broken if the assembly version in \ref\ is lower than the assembly version in \lib\?
Details:
We have a class library compiling against .NET Standard 2.0... it references Microsoft.Extensions.Configuration.Json.
MimExtension
\--Dependendencies
\--Packages
\--Microsoft.Extensions.Configuration.Json (5.0.0)
\--System.Text.Json (5.0.0)
\--System.Buffers (4.5.1)
System.Buffers resolves to \.nuget\packages\system.buffers\4.5.1\ref\netstandard2.0\System.Buffers.dll. The file version in that directory is 4.6.28619.1, date 2020/02/19. .NET Reflector shows the assembly version as 4.0.2.0.
The \lib\ version of that DLL is \.nuget\packages\system.buffers\4.5.1\lib\netstandard2.0\System.Buffers.dll... same file version and date, but the assembly version is 4.0.3.0.
Compiling the DLL gives me a .dll.config file with binding redirects that I could copy into the consuming application's app.config - but System.Buffers.dll and System.Text.Json.dll aren't there. Microsoft.Extensions.Configuration.Json.dll also isn't there - though another nuget package, Microsoft.Extensions.Configuration.Abstractions.dll, is.
I'm assuming this means the compiler thinks no redirect is necessary for the DLLs that aren't in there (see question #3). It makes sense that only DLLs with conflicts across references get added to the binding redirects (if that's what's happening), but conflict or not, our app won't bind to the \lib\ version of the System.Buffers.dll the compiler uses and RTE's (question #1).
To resolve this I can add binding redirects manually. But how do I look at all the nuget references in my project and determine (recursively) what version was chosen for each dll? Short of dumping verbose build output to a text file with some fancy regex and an hour of copy and paste, that is (question #2).
Note: I can add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to the .csproj file and get all referenced dlls dumped to the output directory - including .NET dlls like System.Threading.dll and System.Runtime.CompilerServices.Unsafe.dll- but that still doesn't get me a full list of what versions each one are... especially since I need assembly versions, which I can't even display in explorer.
Regarding that... some of the binding redirects generated automatically are for .NET assemblies like System.Threading... does VS really expect me to deploy the version of System.Threading I compiled against? For that dll, I have newVersion="4.0.11.0"... our server has assembly version 4.0.0.0, file version 4.8.3761.0. VS expects me to deploy assembly version 4.0.11.0, file version 1.0.24212.01 (wtff?!?). The 4.0.11.0 version pulled down by nuget is dated 2019/12/26... the 4.0.0.0 server version is dated 2021/01/21.
I'm guessing that's a Core vs. Framework versioning wtf - but binding redirects don't care. The app that will load our library is .NET Framework 4.8... am I supposed to deploy the System.Threading 4.0.11.0 dll with my app, or manually change the binding redirect and let it load the server's version? It's absolutely ludicrous that a core DLL has a higher assembly version than its newer .NET Framework counterpart (question #addingnewonesasigo).
So when we're referencing nuget packages, how do we know what needs deployed and what doesn't (or worse, shouldn't be)? (question #4) I feel like the build process should copy dlls that aren't part of the framework/won't be in the GAC to the output directory - but there's nothing TIAO to indicate that in the nuget package specs.
Regarding #5... shouldn't the dlls in a nuget package have the same version in the \ref\ and \lib\ folders? The breakdown in Microsoft.Extensions.Configuration.Json is in System.Text.Json... S.T.J's .nuspec lists a .NET Standard 2.0 dependency to <dependency id="System.Buffers" version="4.5.1" />. So why would the System.Buffers.dll nuget cache have different versions in \ref\ and \lib\? Shouldn't they both be either 4.0.2.0 or 4.0.3.0?
There are a lot of questions out there on this - even some specifically to System.Buffers. But nobody has resolved this satisfactorily (that I can find) for a class library. I'm going to try adding a scratch website to the solution and reference the library - just to see whether .NET gets the necessary dlls/redirects in place for its only love: Web
Update
I manually added a binding redirect to 4.0.3.0 for System.Buffers... and immediately got the next mole to whack: Could not load file or assembly 'System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
And so it will go, until we find a way to list everything that VS probed. And without 100% regression coverage, there's no guarantee we won't miss something when we deploy.

For an executable, dotnet publish; and ship the resulting folder is always correct.
But for a dll compiled against .net standard; I've only had success building a nuget package and referencing it and letting the compiler (whole package thereof) figure out what final dlls the project needs. You can make a nuget package with dotnet pack.
I have never needed binding redirects to link .netstandard to .net framework.

Compiling the library for specific platforms pulls the dependent DLLs into the bin folder. This makes sense in retrospect - compiling for .NET Standard is only meaningful when the target platform isn't known and won't be chosen by the developer of the library. That scenario requires a centralized package manager.
Targeting for .NET 4.8 (highest version currently supported by MIM) gave us the DLLs in the bin directory and set binding redirects in the config file.
That said, the System.Buffers.DLL version issue only went away because the .NET 4.8 dependencies were defined correctly. The Microsoft.Extensions.Configuration.Json .nuspec indicates a different assembly version than the dll that gets downloaded when compiling for .NET Standard 2.0. I don't know if that's an issue with the references when the .NET developers compiled the nuget package or an unavoidable artifact of nuget packaging itself.

Sqlite Unable to load DLL 'SQLite.Interop.dll' when set to x86, Could not find type 'xxx' when set to x64?

Trying to use Sqlite in my VB.net app, thought it would be simple so I installed it via the NuGet package manager. Now i've lost a week to this hate to admit, I just can't make it work for the life of me.
When I set my build to x86, it say's it can't load SQLite.Interop.dll, when I set my build to x64 it can't find one of my custom controls within my project. I tried some solutions from other SO questions but none of them worked for me.
Can someone help me out here? It's getting pretty frustrating. Apparently their NuGet package is completely broken for me, so I downloaded just System.Data.SQLite.dll from the vendors website, referenced it in my project, set to Copy Always, and changed my build from AnyCPU to x86 (to match the DLL). Which results in an exception stating the referenced assembly cannot be found.

you also need to download the SQLite package from here http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
make sure you download abd install the x86 version even if your running x64.

critical runtime error after upgrading application with .NET assembly dependencies

I am upgrading an application and running into some issues with it.
Now the old application was version 1.0 and loading a depedency assembly A at version 2.1.1 The assembly is present in application local directory.
I am upgrading the new application to version 2.0 that will load assembly A version 1.0.1 which is present in its application local directory. I've checked application references using ISpy and confirmed the new application references A version 1.0.1
But when I start the new application (v 2.0), it is still trying to load assembly version 2.1.1 and failing. I checked the app.config, machine.config and GAC and there is no redirection for version of assembly A. I also checked fusion log files but don't see any redirection. All I see is the fusion log is that application prebinds A at version 2.1.1 and hence fails to set up the assembly present in its local directory.
Is there something I am missing here? What could be the possible reasons for application still referencing the older assembly at runtime?
Update: Using some tools, I realized the the older assembly is being referenced from a native DLL that is referenced by my application, but I don't know which third party DLL is that, and the application loads a ton of them. The fusion log confirms it by logging "Calling assembly : (Unknown)." for the missing assembly.
Now my next step is to find which dll is referencing the wrong assembly and fix that. Now the problem is that ILSpy tool doesn't show the native DLLs references, and DLLDepends tool does not show the assemblies references, so I am not able to link the two.
thanks

Since the library your trying to reference is supposed to be apart of the GAC; you may want to try:
Control Panel
Small Icons(Administrative Tools)
Event Viewer
Application
Windows itself should throw an exception with some particular details it's attempting to reference when it has an error. Especially if it's apart of the GAC. It was more helpful for me to hone in mscoree.dll and mscorelib.dll libraries fairly easy. Granted those clients that I used that for had corrupt framework; but Event Viewer told me the exact library that it had an issue with.
You may want to try that. Not sure which library; but keep in mind this is usually beneficial to libraries that are found within the %windir%/Assembly folder. Hope that helps.

Azure package contains incorrect DLL

In my web and worker roles, I am referencing an alternative version of a core framework DLL. The file is marked Copy Local. Visual Studio shows the correct version in as a project reference. When compiling the project, the bin directory also contains the correct version.
However, when I ask Visual Studio to create an Azure package, the package (and the csx folder created during packaging) contains the wrong (original) DLL for the Worker role only. The Web role has the correct DLL. This does not occur if I manually use cspack, but that's not really a desirable way to package.
What could cause Visual Studio to compile with the correct reference DLL but bundle the wrong one?
Additional info:
When I run msbuild to do the packaging instead of Visual Studio, I see the following two lines:
Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
So, it seems to copy my reference, and then copy over it with the system reference.
Note: I'm well aware that the entire concept of replacing a .NET CLR DLL is a huge hack. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out. In the meantime, I need to be able to continue development.
This is a replacement to question "Azure References Incorrect DLL", which was actually factually incorrect and lead to answers that were valid, but did not solve my problem.

Even if a Visual Studio project has a reference to a local and/or modified copy of a assembly that is in the GAC, it will be used during the compilation, but at runtime, the CLR will always load the assembly from the GAC, even if it is sitting right there in the same directory as your application.
So the solution does not involve figuring out a clever way to pack or deploy the modified assembly, but figuring out a way of making the CLR actually load it if it's there.
Two possible solutions:
1) Use a role startup task and an installation project to deploy the modified version of the assembly in the production server's GAC.
2) Remove the signature of the assembly and make sure all references are made to this version without the signature. Beware other assemblies that may be referencing the original signed version and will try to load it from the GAC.
For more details and links see How to prevent a .NET application to use an assembly from the GAC?