We Keep Coding

Could not load file or assembly Microsoft.Data.SqlClient, Version=5.0.0.0

Facing following issue after deploying app to azure app service:
Unhandled exception. System.IO.FileNotFoundException: Could not load
file or assembly 'Microsoft.Data.SqlClient, Version=5.0.0.0,
Culture=neutral, PublicKeyToken=***********'. The system cannot find
the file specified.
Locally everything works as fine.
Microsoft.Data.SqlClient presented in site/wwwroot
Runtime Stack: Dotnetcore - 6.0
Main app and all class libs on .net6
Server Operating System: Linux
Microsoft.Data.SqlClient presented as reference from Microsoft.EntityFrameworkCore.SqlServer (v.7.0.2)
Tried different kinds of Nuget Packages versions - still have same issue
Tried to install Microsoft.Data.SqlClient (latest version & 5.0.0.0) directly into projects - still the same

The solution for us was to:
Locate the actual DLL file (Microsoft.Data.SqlClient.dll) on the developer's desktop filesystem (easy to find; once you're referenced it using NuGet it gets copied to multiple places)
Add it to the web project (we placed it right in the root)
Mark it (via Properties tool window) as Copy Always
Step 3 results in our .csproj file looks like this:
<ItemGroup>
<None Update="Microsoft.Data.SqlClient.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>

"Not a valid framework" (MM0140) error when trying to build Xamarin native bindings library for framework targeting net6-macos

I have working native bindings library targeting old xamarin.mac (xamarin.full net framework 4.8) built with mono.
It is binding ScritptingBridge.framework, not a static library. It is builds and works as expected.
Note: full project for experiments may be found here: https://github.com/snechaev/net6nativeBindingsError
Now I'm trying to migrate to newest net6-macos. To do so I do the following
converted main app project to the sdk style and target net6-macos. If I will temporary remove native bindings dependencies, this will build fine.
converted native bindings project to the sdk style and perform the following fixes suggested by the comiler errors
changed version to avoid wildcards
replaced [assembly: LinkerSafe] with AssemblyMetadata("IsTrimmable", "True")]
added explicit NativeReferecnce to the framework I'm trying to bind.
Final csproj content for native bindings project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6-macos</TargetFramework>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<RootNamespace>NativeBindingsLib</RootNamespace>
<AssemblyName>NativeBindingsLib</AssemblyName>
<IsPackable>false</IsPackable>
<AllowUnsafeBlocks>false</AllowUnsafeBlocks>
<IsBindingProject>true</IsBindingProject>
<NoBindingEmbedding>true</NoBindingEmbedding>
</PropertyGroup>
<ItemGroup>
<ObjcBindingApiDefinition Include="ApiDefinition.cs" />
<ObjcBindingCoreSource Include="StructsAndEnums.cs" />
<NativeReference Include="/System/Library/Frameworks/ScriptingBridge.framework" Kind="Framework" />
</ItemGroup>
</Project>
When I trying to build the only bindings library with dotnet build it builds without errors.
But when I try to build the application project (app.csproj in the sample repository), which is referencing (via the the ProjectReference) the binding library, I got the following errors:
ILLINK: Error MM0140: File '/Users/user/work/MonoBindingTest/net6/app/obj/Debug/net6.0-macos/osx-x64/linker-cache/NativeBindingsLib.resources/ScriptingBridge.framework/ScriptingBridge' is not a valid framework. (MM0140) (app)
ILLINK: Error MM2342: The linker step 'Extract Binding Libraries' failed during processing: File '/Users/user/work/MonoBindingTest/net6/app/obj/Debug/net6.0-macos/osx-x64/linker-cache/NativeBindingsLib.resources/ScriptingBridge.framework/ScriptingBridge' is not a valid framework. (MM2342) (app)
I double checked the framework path and it is ok. I also tried to add ScriptingBridge.framework into the XCode project and verified that the path is the same.
I also will be happy to get any samples of working net6-macos targeted native bindings projects for frameworks (not a static libraries) for further experiments on my own.
Full project mey be found here (both mono-targeted and net6-targeted): https://github.com/snechaev/net6nativeBindingsError

Finally, I posted the issue in the xamarin repo on github https://github.com/xamarin/xamarin-macios/issues/15485.
And ducting the discussion and experiments we concluded the following:
MM0140 is because the ScriptingBridge is the system framework and this is the special case.
you should not use NativeReference for the system frameworks as it will try to copy the framework into your bundle and this is not what you want for the system framework
initially I was missleaded by the following error
MSBuild : error MM7068: Can't create a binding resource package unless there are native references in the binding project.
so I decided to add NativeReference pointing ScriptingBridge.
So, the final solution is that the "at least one NativeReference" compiler check is excessive and it will be removed it net7 (https://github.com/xamarin/xamarin-macios/issues/15489).
The temporary workaround for net6 is to add the fake NativeReference to the empty static library to make compiler happy.
<NativeReference Include="/Users/sergey/work/MonoBindingTest/net6/test.dylib" Kind="Static"/>
I believe that it is possible to specify NativeReference to point to the source code (C++) instead of binary file and provide an additional command to build such a C++ code into the binary during the build process of native bindings library.
Additional note: the MM0140 error was called MT0140 in the previous versions of xamarin. So, this note may help other to find this post.

VS2019 extension using IDebugEventCallback2

I created a new VS extension using VS2019 16.1.6.
and I added this using statement
using Microsoft.VisualStudio.Debugger.Interop;
and added the interface IDebugEventCallback2 to my class
public sealed class VSIXProject1Package : AsyncPackage, IDebugEventCallback2
Not I get the error:
error CS0433: The type 'IDebugEventCallback2' exists in both 'Microsoft.VisualStudio.Debugger.Interop, Version=8.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Debugger.InteropA, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
How can I get rid of this error? Or is there an other way to react to debugger events than using IDebugEventCallback2?
edit:
Problem reported to Microsoft:
https://developercommunity.visualstudio.com/content/problem/651199/vs2019-extension-using-idebugeventcallback2.html

VS2019 uses PackageReference format to manage nuget packages for VSIX project.
And by default it will reference Microsoft.VisualStudio.SDK and Microsoft.VSSDK.BuildTools package.Also, since Microsoft.VisualStudio.SDK package have dependencies on many other packages, this project will also reference those packages.
See this simple structure:
Microsoft.VisualStudio.SDK
......(other dependencies)
--Microsoft.VisualStudio.Debugger.Interop
--Microsoft.VisualStudio.OLE.Interop
--Microsoft.VisualStudio.Debugger.Interop.10.0
--Microsoft.VisualStudio.Debugger.InteropA
......(11.0,12.0,14.0,15.0)
--Microsoft.VisualStudio.Debugger.Interop.16.0
--Microsoft.VisualStudio.Debugger.InteropA
So it's clear this issue results from the VSIX project adds reference to both Microsoft.VisualStudio.Debugger.Interop and Microsoft.VisualStudio.Debugger.InteropA.
These two assemblies have the same namespace Microsoft.VisualStudio.Debugger.Interop, and all have IDebugEventCallback2 Interface. I think it's why causes this issue.
As a workaround:
Normal we can use extern alias for this situation. But it hasn't supported for PackageReference format yet. Fortunately I found a good hint from gertjvr. So all we need is:
Unload the project=>Edit the xxx.csproj=>Add the content below into the project file:
<Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition="'%(FileName)' == 'Microsoft.VisualStudio.Debugger.Interop'">
<Aliases>signed</Aliases>
</ReferencePath>
</ItemGroup>
</Target>
You can change the ReferencePath to Microsoft.VisualStudio.Debugger.InteropA if you want to use the Interface from this assembly. It depends on your need.

Error: Could not load file or assembly 'Microsoft.Win32Registry' from .NET Standard Library Consumed by .NET Framework Console App

The Problem
The Microsoft.Win32.Registry nuget package is giving me a lot of issues . We had .NET Framework 4.7.2 library that had a helper class that used that package and worked fine from a .NET Framework 4.7.2 unit test project. We recently converted the library to target .NET Standard 2.0, and now this class breaks when used with the following error:
ERROR: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Win32.Registry, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.Win32.Registry, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at NetStandardRegistryLib.RegistryUtil..ctor(String remoteMachineName)
at NetStandardRegistryLib.Program.Main(String[] args) in C:\src\Microsoft.Win32.Registry-IssueRepro\FrameworkRegistry\RegistryEditor\Program.cs:line 21
When I look at output of the Console project, I don't see the Microsoft.Win32.Registry.dll in the output.
Using ILSpy and loading my .exe - it seems it would try to resolve the .dll from my dotnet core installation, which wouldn't work since it's a .NET Framework app.
To Reproduce
I've created a repo that reproduces for me on my Windows 2010 machine. You can find it here: https://github.com/TylerNielsen/Microsoft.Win32.Registry-IssueRepro
Clone the repo, then open and build the RegistryEditor project.
Using Powershell or your favorite editor - call the tool with three required arguments [remoteMachineName] [Environment variable name to set] [Value to set on the environment variable] **
** Note, this actually requires a remote machine you can reference by IP address. For some reason using 127.0.0.1 doesn't work for me, but I'm unsure why. The use case for this utility is for accessing remote machine environment variables.
Other Notes
When I create a .NET Framework Class Library to use for unit tests and reference the same .NET Standard Library - the Microsoft.Win32.Registry package is included and the utility runs just fine.

In your repo, if you look into both csproj files you'll see they are quite different. The NetStandardRegistryLib.csproj is the new format, the RegistryEditor.csproj is the old one.
Your problem is that old style projects do not resolve dependencies transitively. RegistryEditor will not copy dependencies of its own dependency NetStandardRegistryLib.
There are at least two ways to solve your problem:
Just add Microsoft.Win32.Registry Nuget package to RegistryEditor project explicitly. That'll make the Microsoft.Win32.Registry.dll to appear in the RegistryEditor build folder.
Convert the RegistryEditor.csproj to new format. It's not limited to netstandard builds, you can use it for builds targeting .Net Framework versions as well. And it does resolve dependencies transitively!
Here's a long guide for how to do the conversion in general https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
Since your project is quite simple, I've converted it for you. Just replace the content of RegistryEditor.csproj with the code below. It's still targeting net472.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<AssemblyName>RegistryEditor</AssemblyName>
<RootNamespace>RegistryEditor</RootNamespace>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\NetStandardRegistryLib\NetStandardRegistryLib.csproj" />
</ItemGroup>
</Project>
Note that several properties that used to be in AssemblyInfo.cs file are provided by csproj file properties now, so you need to remove them from AssemblyInfo.cs to fix compilation errors:
[assembly: AssemblyTitle("RegistryEditor")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("RegistryEditor")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Missing project dependency when referring project

I'm facing some issues with dependencies when referring projects in Visual Studio. Here is how my solution ReferenceTest is structured:
Common. A class library containing a static CommonClass.HelloWorld() method returning a string. The string returned by this method is read from a JSON config file using Microsoft.Extensions.Configuration (and a large set of its dependencies) installed using NuGet.
ConsoleApplication1. A console application writing the CommonClass.HelloWorld() string to the console using a static Worker.DoWork() method. This console application has a project reference to the Common project.
ConsoleApplication1Test. A class library using NUnit for testing that the Worker.DoWork() method from the ConsoleApplication1 is returning the expected string. This class library has a project reference to the ConsoleApplication1 project.
The ConsoleApplication1 console application is working as expected, but when running the unit test in ConsoleApplication1Test I get this exception:
System.IO.FileNotFoundException : Could not load file or assembly
'System.Runtime, Version=4.1.1.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
The System.Runtime.dll file (and perhaps others) is not copied to the bin-folder when compiling the ConsoleApplication1Test project. Why is this happening?
A zip-file with the demo solution can be found here:
http://www.filedropper.com/referencetest

Solution
I was able to reproduce and resolve this issue, and generate build logs that illustrate the differences.
First, the solution. I noticed that the ConsoleApplication1.csproj file had a line of configuration that the Test project did not. So, I added:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
to the Test project file. The first <PropertyGroup> section now looks like this:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{A97E82A2-2EF9-43AB-A46B-882131BAF1D0}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>ConsoleApplication1Test</RootNamespace>
<AssemblyName>ConsoleApplication1Test</AssemblyName>
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
The unit test now fails because it can't find config.json. Success!
Edit: after running the build from the command line per below, the unit test passed. I'm not sure why config.json wasn't present when building from Visual Studio.
Partial Explanation
This AutoGenerateBindingRedirects property seems to change the way that the build process resolves references to libraries that are part of the .NET Framework. For example, a before and after verbose log output comparison shows that:
Unified Dependency "System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.Abstractions.dll" because there is a more recent version of this framework file. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.dll" because there is a more recent version of this framework file. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.Binder.dll" because there is a more recent version of this framework file. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Primitives.dll" because there is a more recent version of this framework file. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.FileProviders.Abstractions.dll" because there is a more recent version of this framework file. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\System.Runtime.CompilerServices.Unsafe.dll" because there is a more recent version of this framework file. (TaskId:97)
Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\Facades\System.Runtime.dll". (TaskId:97)
Reference found at search path location "{TargetFrameworkDirectory}". (TaskId:97)
Changes to:
Unified Dependency "System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.Abstractions.dll" because AutoUnify is 'true'. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.dll" because AutoUnify is 'true'. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Configuration.Binder.dll" because AutoUnify is 'true'. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.Primitives.dll" because AutoUnify is 'true'. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\Microsoft.Extensions.FileProviders.Abstractions.dll" because AutoUnify is 'true'. (TaskId:97)
Using this version instead of original version "4.0.0.0" in "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\System.Runtime.CompilerServices.Unsafe.dll" because AutoUnify is 'true'. (TaskId:97)
Resolved file path is "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug\System.Runtime.dll". (TaskId:97)
Reference found at search path location "C:\Users\User\Desktop\ReferenceTest\ConsoleApplication1\bin\Debug". (TaskId:97)
I'd imagine that the assembly binding redirects in the app.config file are influencing some aspect of the assembly reference path resolution during the build process. This is supported by the appearance of this build output, only after adding the specified property:
Added Item(s):
_ResolveAssemblyReferencesApplicationConfigFileForExes=
app.config
OriginalItemSpec=app.config
TargetPath=ConsoleApplication1Test.dll.config
I have not seen this particular property before and I don't know why it would be included in some projects but not others, or if there is a UI to alter this setting.
For reference, to produce the build output comparisons above, I did the following:
Load the project from the link provided in the question
Add the NUnit3TestAdapter NuGet package to the Test project (personal preference - the error was present when using the VS test runner)
Run the tests to verify the errors
Clean the solution
Run msbuild /verbosity:diag ReferenceTest.sln > build.txt from the Developer Command Prompt in the solution folder
Modify the Test project as described above
Run msbuild /verbosity:diag ReferenceTest.sln > build2.txt
Run devenv /diff build.txt build2.txt or your favorite compare tool

It seems that Newtonsoft.Json library which you are referencing from Common is referencing by itselft to System.Runtime ver 4.0
But all your project are targeted to 4+ framework.
That`s the point of conflict.
Try upgrade or reinstall NuGet package with Newtonsoft.Json library or downgrade the targeted framework of all project to ver 4.0.