I have upgraded one of my XamarinForms Class library projects to .NetStandard2.0 and now when I add the nuget package to my other .NetStandard2.0 project it does not let me compile it and shows me some 8000 errors like this one:
/Volumes/Data/Projects/Project1App copy/Project1/Project1.Android/CSC: Error CS1703: Multiple assemblies with equivalent identity have been imported: '/Users/drtj/.nuget/packages/royalxamarincomponents/1.1.3/lib/netstandard2.0/System.Xml.XmlSerializer.dll' and '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.XmlSerializer.dll'. Remove one of the duplicate references. (CS1703) (Project1.Android)
or this
/Volumes/Data/Projects/Project1App copy/Project1/Project1.Android/CSC: Error CS1703: Multiple assemblies with equivalent identity have been imported: '/Users/drtj/.nuget/packages/royalxamarincomponents/1.1.3/lib/netstandard2.0/System.Threading.dll' and '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Threading.dll'. Remove one of the duplicate references. (CS1703) (Project1.Android)
Try to open your project's .csproj file and add below codes into the <ItemGroup>.
<PackageReference Include="RoyalXamarinComponents" Version="1.1.3" >
<PrivateAssets>all</PrivateAssets>
</PackageReference>
Related
When trying to build Avalonia application in release configuration it crashes with "XamlParseException when building in Release with DataGrid". In debug mode works perfectly
Adding Avalonia.Controls.DataGrid nuget package directly solves problem, but seems a little bit strange
After some search i found a solution:
In cproj file after:
<!--Condition below is needed to remove Avalonia.Diagnostics package from build output in Release configuration.-->
<PackageReference Condition="'$(Configuration)' == 'Debug'" Include="Avalonia.Diagnostics" Version="0.10.18" />
Just add the line:
<PackageReference Condition="'$(Configuration)' == 'Release'" Include="Avalonia.Controls.DataGrid" Version="0.10.18" />```
Actually I'm trying to use the two libraries Microsoft.Graph and Microsoft.Graph.Beta in parallel within my solution.
To get this to work, you can use aliases within references. For this purpose you first have to write within your .csproj file something like this:
<PackageReference Include="Microsoft.Graph" Version="4.25.0" />
<PackageReference Include="Microsoft.Graph.Beta" Version="4.40.0-preview">
<Aliases>GraphBeta</Aliases>
</PackageReference>
After that within your .cs file at the top you can write something like this:
extern alias GraphBeta;
using Beta = GraphBeta.Microsoft.Graph;
using Microsoft.Graph;
And within your code you can access both parts individually like this:
var client = new GraphServiceClient(new HttpClient());
var betaClient = new Beta.GraphServiceClient(new HttpClient());
So far so good.
Unfortunately within my solution I'm using the above code within a library project. This library project is referenced by my application project and within my application project I also need to make some calls to Microsoft.Graph only. After adding the beta package to my library project I'm getting compiler errors from my application project like this:
error CS0433: The type 'IMessageAttachmentsCollectionPage' exists in both 'Microsoft.Graph.Beta, Version=4.40.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.Graph, Version=4.25.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
So it seems, the given alias to the NuGet package within my library project doesn't flow upwards to my application project. My application project doesn't have any direct reference to any of the both Graph libraries, it just consumes it through the indirect dependency from the library project.
Also trying to add the extern alias line to the file within my application project results in this error message:
error CS0430: The extern alias 'GraphBeta' was not specified in a /reference option
Any solution available to either make the alias flowing upwards to my application project or to make the Beta dependency internal to the library project?
After some further try-and-error, my current solution is to add a reference to the Graph.Beta assembly (including the alias) explicitly to the application project. After that the error message is gone.
But this is just a simplified example. In my real project I have a deeper structure of multiple library projects and now every project that needs to use the Microsoft.Graph namespace needs to get an explicit package reference with the alias to the Beta package. For example if you have a test project for your library project, it must explicitly reference the Beta package including the alias if it tries to use any type from the Microsoft.Graph namespace within a test.
In our .NET Core 3.1 project (REST API), we've multiple NuGet packages. General packages comes from the nuget.org source, some custom made packages are retrieved from a private source.
In Azure DevOps, we've a build pipeline with a task to restore the NuGet packages. Here we saw that every packages was checked with every source. A general package such as Swashbuckle.AspNetCore.SwaggerGen was also searched on our private source.
Due to the amount of requests from DevOps, the first attempt of the pipeline was interpreted as a DOS attack on our system. When the failed run was started again, the task succeeds without any error.
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: 'restore'
projects: '**/*.sln'
feedsToUse: 'config'
nugetConfigPath: 'src/NuGet.config'
In the tasks detail, we see the below message returning for every package.
GET private_source/nuget/FindPackagesById()?id='xunit.analyzers'&semVerLevel=2.0.0
Retrying 'FindPackagesByIdAsyncCore' for source 'private_source/nuget/FindPackagesById()?id='Microsoft.AspNetCore.Mvc.Razor'&semVerLevel=2.0.0'.
An error occurred while sending the request.
The response ended prematurely.
How can we avoid that every package in our solution, is checked at every NuGet source? Or what can we change to get a successfull build the first time?
NuGet recently introduced the feature, called Package Source Mapping: https://devblogs.microsoft.com/nuget/introducing-package-source-mapping/
Here's the nuget.config snippet from the blog post:
<!-- Define my package sources, nuget.org and contoso.com. -->
<!-- `clear` ensures no additional sources are inherited from another config file. -->
<packageSources>
<clear />
<!-- `key` can be any identifier for your source. -->
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="contoso.com" value="https://contoso.com/packages/" />
</packageSources>
<!-- Define mappings by adding package ID patterns beneath the target source. -->
<!-- Contoso.* packages will be restored from contoso.com, everything else from nuget.org. -->
<packageSourceMapping>
<!-- key value for <packageSource> should match key values from <packageSources> element -->
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="contoso.com">
<package pattern="Contoso.*" />
</packageSource>
</packageSourceMapping>
Regarding the error message:
An error occurred while sending the request. The response ended prematurely.
This suggests there's something wrong with the server or networking. A good nuget server should return HTTP 404 for packages that doesn't exist on it. Implementing package source mapping might not solve your restore problem.
I suggest creating an Azure Devops Artifacts feed having upstream source both from nuget.org and your private feed. There is no other way you can use multiple sources to do partial restore.
How can we avoid that every package in our .NET Core 3.1 project, is checked at every NuGet source during Azure DevOps pipeline?
I am afraid there is no such out of box way to resolve this restriction.
That's because no matter how we set the resource, when we restore the package for the first time, nuget.exe will iterate over each resource for every package. This problem will be alleviated when we run the pipeline again, because it is from nuget.org The packages will be cached in our private feed. When we restore again, it will be retrieved from the private feed first：
Check my previous thread for some more details.
Besides, If you want to avoid this problem the first time, you can try not to restore the entire .sln file, you can choose package.configs for the specify reject:
I needed to migrate a Xamarin.Forms project from PCL to .netstandard. I use the PCL compatibility nuget package to consume PCLs referenced in the project but I am having a problem with DryIoc that I'm not sure why it is happening. I figured maybe someone here has seen this and can help. Basically I'm getting CS0121 errors (call is ambiguous between 'method1' and 'method2' ) One of the errors is below. I replaced part of the path with the ~ but it looks like it is confused with itself.
~/.nuget/packages/dryioc/2.12.7/contentFiles/cs/any/Container.cs(56,56): Error CS0121: The call is ambiguous between the following methods or properties: 'DryIoc.ReflectionTools.GetFieldOrNull(System.Type, string)' and 'DryIoc.ReflectionTools.GetFieldOrNull(System.Type, string)' (CS0121) (Masterflex)
Thanks!
Fixed this error by replacing the PackageReference of DryIoc with a Reference node in the csproj file:
<Reference Include="DryIoc">
<HintPath>..\packages\DryIoc.dll.4.1.0\lib\netstandard2.0\DryIoc.dll</HintPath>
</Reference>
Having what appears to be runtime issues with Project References in Visual Studio 2017 Test Runner. The Unit Test CSPROJ builds just fine with TargetFramework=net47, but at execution time we get the following message from MSTEST or XUNIT. Using Microsoft.NET.Test.Sdk v15.0.0.
Test Execution Error (x86): Serilog Seq Extension
System.MissingMethodException : Method not found: 'Serilog.LoggerConfiguration Serilog.SeqLoggerConfigurationExtensions.Seq(Serilog.Configuration.LoggerSinkConfiguration, System.String, Serilog.Events.LogEventLevel, Int32, System.Nullable1<System.TimeSpan>, System.String, System.String, System.Nullable1, System.Nullable1<Int64>, Serilog.Core.LoggingLevelSwitch, System.Net.Http.HttpMessageHandler, System.Nullable1, Boolean, Int32)'.
Unit Test Example - Serilog
[Fact]
public void TestMethod1()
{
LoggerConfiguration loggerConfig = new LoggerConfiguration();
loggerConfig.MinimumLevel.Debug();
loggerConfig.WriteTo.LiterateConsole();
loggerConfig.WriteTo.Seq("http://localhost:65454");
}
If we reference net462 projects, we get the same result so we believe it is related to VS 2017, not .NET Framework version. We have never seen this error with VS 2015. Seems like there is an issue loading DLL extensions with optional parameters / matching signatures, etc. The method clearly exists or it wouldn't compile - why at runtime is this crashing out?
If I just use local nuget packages it works fine - this only seems to be a problem when referencing any Projects via ProjectReference in .NET Core CSPROJ. It doesn't seem to handle the dependency tree properly.
Another example using KeyVault where VS Test Runner cannot find the extension methods properly...
Test Execution Error (x86): KeyVault Extension
Message: System.MissingMethodException : Method not found: 'Void Microsoft.Azure.KeyVault.KeyVaultClient..ctor(AuthenticationCallback, System.Net.Http.DelegatingHandler[])'.
Unit Test Example - KeyVault
[Fact]
public void TestMethod1()
{
KeyVaultClient _kvClient = new KeyVaultClient(new AuthenticationCallback(getKeyVaultToken));
}
private static async Task<string> getKeyVaultToken(string authority, string resource, string scope)
{
var authContext = new AuthenticationContext(authority);
ClientCredential clientCred = new ClientCredential("test", "account");
AuthenticationResult result = authContext.AcquireTokenAsync(resource, clientCred).Result;
if (result == null)
throw new InvalidOperationException("Failed to obtain the JWT token");
return result.AccessToken;
}
Discovered this odd issue with dotnet test is two-fold. After running dotnet test --diag and reviewing the output, it led me to realize there are newer releases of Microsoft.NET.Test.Sdk which version 15.0.0 was masking the real problem. Once I upgraded the nuget to 15.3.0-preview-20170502-03, a different exception appeared.
Error Source: Microsoft.Rest.ClientRuntime
System.TypeLoadException: 'Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.'
Now this is interesting - the MissingMethodException was masking the real problem which was buried in System.Net.Http. The second realization is that this base library has a bug which prevents the type from being loaded. Once I nuget updated System.Net.Http to version 4.3.1, the issue went away and my Project References started working again.
Conclusion
Update Microsoft.NET.Test.SDK to latest preview and System.Net.Http to latest version to get past the weird MissingMethodException with dotnet test. You can track the open issue on github here.
Option #2 - Excluding Package Reference Assets
For latest VS 2017 CSPROJ formats - the following config also fixes this as it supresses copying System.Net.Http to the Build Output path which by default loads the GAC'd version 4.0.0.0.
<PackageReference Include="System.Net.Http" Version="4.3.1">
<ExcludeAssets>All</ExcludeAssets>
</PackageReference>
Option #3 - Assembly Binding Redirect
dotnet core will follow any runtime binding redirects you place in your app.config, so any nuget dependencies you have to System.Net.Http to version 4.1.*, you can redirect to the latest version or revert to the last stable version 4.0.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<!-- Another PackageReference dependency binds to 4.1.1 which is busted, we leverage .NET Core redirection and revert to CLR 4.0.0 -->
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I encountered this issue while testing a class from a project that had a dependency on a Nuget package that had been updated in the project being tested, but not in the test project (which was the source for the missing method).
The solution was as simple as upgrading the affected Nuget in the test project:
Right-Click the test project > Manage Nuget packages > Upgrade necessary packages
I am working on a SharePoint plug-in and the plug-in has been installed on the server that I am also using to do development. Therefore, I think the DLL is in the GAC and that DLL is being picked up first!
I was getting the MissingMethodException from the test runner. So I came up with an easy fix.
Change the version number in AssemblyInfo.cs! This will make the version number in the GAC and the one in your bin/Release directory different, so the test runner will use the correct DLL. Phew!
See also:
System.MissingMethodException: Method not found?