We Keep Coding

How to resolve conflict between two nuget packages that have the same name

I am using both ExcelDataReader.Mapping - 2.2.2 and ExcelMapper - 5.2.429 nuget packages in a project. I know it seems redundant, however, one of these projects gives a little more flexibility that I need when reading excel files. It seems there is some conflict between namespaces and classes between these two projects. To fix that, I have ExcelDataReader.Mapping aliased as ExcelReader and ExcelMapper as ExcelWriter. This worked briefly, but now I am running into another issue.
I get the following message on build of the project: warning MSB3243: No way to resolve conflict between "ExcelMapper, Version=5.0.0.0, Culture=neutral, PublicKeyToken=6c3f2bec99465df3" and "ExcelMapper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null". Choosing "ExcelMapper, Version=5.0.0.0, Culture=neutral, PublicKeyToken=6c3f2bec99465df3" arbitrarily.
Using the diagnostic build, I also see this error: Encountered conflict between 'Runtime:C:..\.nuget\packages\exceldatareader.mapping\2.2.2\lib\netstandard2.0\ExcelMapper.dll' and 'Runtime:C:..\.nuget\packages\excelmapper\5.2.429\lib\netstandard2.0\ExcelMapper.dll'. Choosing 'Runtime:C:..\.nuget\packages\excelmapper\5.2.429\lib\netstandard2.0\ExcelMapper.dll' because AssemblyVersion '5.0.0.0' is greater than '1.0.0.0'.
It appears they are using the same name for the .dll file, so it is causing some confusion as to which one it should use. Is there a way to change the .dll file name when installing packages? Or some way to register a full path when referencing the .dll file?

Fixing "They type 'X' exists in both 'Y' and 'Z'" C# error for System.ServiceModel in LINQPad

If I:
Create a new C# query in LINQPad 6.
Add the System.ServiceModel.Http NuGet package or another package that references it.
Try to instantiate a class from the System.ServiceModel namespace, for example System.ServiceModel.BasicHttpBinding.
Leading to the following .linq file:
<Query Kind="Expression">
<NuGetReference>System.ServiceModel.Http</NuGetReference>
</Query>
new System.ServiceModel.BasicHttpBinding()
Then I get a compile error:
CS0433 The type 'BasicHttpBinding' exists in both 'System.Private.ServiceModel, Version=4.7.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.ServiceModel.Http, Version=4.7.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
If I create a project in Visual Studio and add the same NuGet package and code, I do not get this error.
According to the C# Language reference for the error, it should be possible to resolve by using the -reference compiler option or by not referencing one of the assemblies. However, I can't seem to find a way to use this compiler option in LINQPad, nor can I find any way to remove the assembly reference to System.Private.ServiceModel.
How can I fix the error?

This is a bug in LINQPad, triggered by an obscure scenario. The System.Private.ServiceModel package contains a lib folder with an assembly which is required at runtime, and a ref folder with a underscore.underscore file which indicates that no assemblies should be referenced by the compiler. Because LINQPad finds no reference assemblies, it feeds the compiler the assembly in the lib folder, which causes the error.
I've got a fix ready and regression tests are currently running. The fix will likely make it into the 6.11.2 beta build, which should be released in a day or two.

xamarin intent extension with netstandard cause MT2001 error

I'm trying to add siri intent to my application.
I've created intent extensions project, than created ios library project (kit project as in a documentation) which has reference to .netstandard project with shared logic (core).
The core project use MvvmCross and when i'm trying to build main application it cause to:
error MT2001: Could not link assemblies. Reason: Error while
processing references of 'Diabetto.iOS.Intents, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null'
With more detailed logs i've known a reason of this error:
Error while processing references of 'Diabetto.iOS.Intents' --->
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly:
'MvvmCross, Version=6.4.1.0, Culture=neutral, PublicKeyToken=null'
---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'MvvmCross, Version=6.4.1.0, Culture=neutral,
PublicKeyToken=null'
I've tried to add nuget reference to iOS class library, to iOS intent library (unsuccessful, got error
Failed to add reference. The package 'MvvmCross' tried to add a
framework reference to 'System.Drawing.Common.dll' which was not found
in the GAC
VS 2019 16.3.5, iOS project 13.1
To be clear, my project structure
and link to project

Solved this problem.
Explicit add nuget reference to System.Drawing.Common and MvvmCross.
Problem was in System.Drawing.Common, VS is trying to use GAC version. With nuget reference it use .net standard version.

Why do I receive a warning about an assembly reference that appears to be identical in version and culture

I am using Xamarin on a Mac and have built up a series of .netstandard1.3 libraries. One of which is referencing a few external packages:
NETStandard.Library
Newtonsoft.Json
System.Linq.Queryable
System.Reactive
System.Security.Principal
When I build the project (library) it builds but with the following warning:
/Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets (CoreCompile target) ->
CSC: warning CS1702: Assuming assembly reference
System.Runtime.Serialization.Primitives, Version=4.1.1.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' matches assembly
System.Runtime.Serialization.Primitives, Version=4.1.1.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
You may need to supply runtime policy
I'm not directly referencing this specific library anywhere, but even if I were the version and public key token appear to be identical so why the complaint? How do I get rid of this warning and why am I getting it?

Despite having the same assembly identity, there are different implementations of System.Runtime.Serialization.Primitives.dll presumably because of runtime specific behavior / implementation. MSBuild is not sure which to use. You may target your library to multiple runtimes, or distribute it as a NuGet package which shifts the responsibility of picking a target runtime to the library or app consuming your package. You can download the package, change it to a .zip and take a peak inside to see what I mean.

ObservableCollection<T> exists in both 'System.Windows' and 'System'

After creating a new WPF project in VS 2017 targeting .NET 4.6 as soon as I try to use ObservableCollection<T> in my code I get the following error which prevents the app from building:
ObservableCollection exists in both 'System.Windows' and 'System'
In my projects I created in VS 2015 I have referenced both of these assemblies and the application worked just fine. I tried deleting contents of app's bin and obj folder, restarting VS and performing Build > Clean Solution but that did not help.
Removing reference to System.Windows allows application to build but that adversely affects other code (for example RaiseCanExecuteChanged of my DelegateCommand requires a reference to System.Windows).
Any idea why this is happening and how to fix it?
UPDATE Here is the full error message:
Severity Code Description Project File Line Suppression State
Error CS0433 The type 'ObservableCollection' exists in both
'System.Windows, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes' and 'System,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

The problem was that ReSharper was adding a reference to:
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile158\System.Windows.dll
instead of:
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.6.2\System.Windows.dll
Once I removed the reference added by ReSharper and manually added the correct reference the problem was resolved.
ReSharper was detecting that DelegateCommand implementation of ICommand used by my MVVM framework needed a reference to System.Windows but was erroneusly adding a reference to System.Windows found in the NETPortable instead of System.Windows found in .NET...