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" />```
Related
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 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>
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?
really. weird. shiz.
When I do a TFS Team Build (with Remote Deploy), some #if DEBUG preprocessor directives code I have on a web page does not get called. When i manually one-click deploy (remote deploy) the preprocessor directive code works. When I debug locally, the code also works.
So - problem looks to be related to my configuration settings for the Build Template i have (I think??). So, this is what I have :-
Nothing too hard. That says ... Please kind Compiler. Build my project (read: project, NOT solution) in 'DEBUG' mode.
The code i have is the following :-
#if DEBUG
Log.Debug("We are in DEBUG mode.");
#else
Log.Debug("We are _NOT_ in DEBUG mode.");
#endif
So when this code (in some aspx page) is called, it prints out "We are in DEBUG mode." when it's
Localhost (Localhost Configuration: Debug)
Remote server with manual One-click reploy (Localhost Configuration: Debug)
But not when i let TFS's continuous intergration kick in.
FML.
I've tried to see if it was a CASING situation (ie #if debug or #if Debug) but it still doesn't work.
I then even tried to explicitly tell MSBuild the configuration....
Still no love.
Oh .. but this is the corker! I ALSO have some web.config transformations
web.config
web.debug.config
web.release.config
... and can u guess which file get's transformed ?? Winner if u guessed web.debug.config for all scenario's ... even the team build which is erroring in the code! So it's like the build process and workflow knows it's a DEBUG configuration .. kewl! but the compiled code doesn't???
Lastly, changing debug="true" or debug="false" makes no difference.
Can someone please help before I jump out of this building? It kills me when, constantly, these weird ass issues pop up in my life. sigh
Please help!
NOTE: I cannot accept anymore donations for the world's smallest violin - I have been given plenty already. Cheers :)
Well, I found the answer, but I'm not too happy with it. I'll make a video of this bug and email it off to Vishal # MS ... to see what he thinks :)
Anyways, if you look carefully at the default configuration everywhere it is this...
DEBUG | Any Cpu
nothing unusual there...
Now, when I change the platform to AnyCpu (notice how i removed the space....) it now works fine.
eg..
What made me think about that was when i checked out the .proj file... .. here's a snippet of that....
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
... snip for brevity ...
<SccProvider>SAK</SccProvider>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
... snip for brevity ...
<DesktopBuildPackageLocation />
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
... snip for brevity ...
<CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
so yeah .. i fixed it but i'm not sure if that is acceptable or just a fluke. I'll need to get some real answers from the MS team :)
I can confirm this behavior as well as the work-around. It looks like VS2010 will automagically remove the space when it either a) saves the Platform value to the solution/project files, or b) removes it when it invokes MSBuild.
Either way, the TFS Build engine does not follow this pattern and it is imperative to remove the space manually if you are selecting specific Platform|Configuration values.
On interesting side note, the TFS Build Definition dialog permits you to enter just the Configuration. It will complain but then accept the input. The advantage of this approach is that the Microsoft.Common.targets file gracefully handles an empty Platform input value by defaulting to "AnyCPU".