When I try to run my program in release mode, it give this error:
Severity Code Description Project File Line Suppression State
Error XAGJS7004 System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Xamarin.Android.Tasks.TypeMapGenerator.GenerateRelease(Boolean skipJniAddNativeMethodRegistrationAttributeScan, List`1 javaTypes, String outputDirectory, ApplicationConfigTaskState appConfState)
at Xamarin.Android.Tasks.GenerateJavaStubs.WriteTypeMappings(List`1 types, TypeDefinitionCache cache)
at Xamarin.Android.Tasks.GenerateJavaStubs.Run(DirectoryAssemblyResolver res)
at Xamarin.Android.Tasks.GenerateJavaStubs.RunTask()
at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 17 MauiApp1 C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\32.0.440\tools\Xamarin.Android.Common.targets 1438
It is strange because in debug mode it works fine and I can't find any answer online.
Window snippet
There is fore sure some incompatibility between MAUI and .NET7, but you can set your project to use previous NET6 version following few steps:
Discover installed SDKs and keep note of the exact version 6
dotnet --info
SDKs list
Move to project folder and create a global.json file, it sets the NET SDK to be used. Be sure to set the installed SDK version:
dotnet new globaljson --sdk-version 6.0.301 --roll-forward disable
Restore workloads required by your project:
dotnet workload restore
Open project in Visual Studio, confirm to reload the project if requred.
Now your project will be built using NET6 SDK.
I solved it by uninstalling .net7, I found on Maui's github page people with the same problem and I think it will be fixed in the future.
It remains a shame Maui is not yet ready for .net7
Had the same problem, working on debug, this exception on release.
I solved it by: Clean Maui solution -> delete bin and obj -> Close Visual Studio -> Rebuild -> Working
Hope this helps if you didn't try
I'm trying to get a Xamarin Forms solution to build from the command line as part of a build script using the command dotnet build <solution.sln>. Most of the projects in the solution build; however, two projects fail with this error message: error MSB6006: "csc.exe" exited with code 1.(on Ubuntu) and error MSB6006: "csc.exe" exited with code 8. (on Mac).
I have running Ubuntu 18.04 (using Windows subsystem for Linux) and MacOS 10.13.6 on separate machines.
I have also tried to run dotnet build <solution.sln> from the windows command line which prints out this error message instead:
error MSB4062: The "XamarinLive.Build.XamarinLiveTask" task could not be loaded from the assembly C:\Users\Jason.nuget\packages\livexaml\2.1.22\build\XamarinLive.Build.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
However, the solution works and builds fine from within VS2017 (Version 15.9.7). I've tried scouring the binary log that is generated but I can't make much sense of it and there doesn't seem to be any obvious errors (on Ubuntu & Mac). Could the windows error message be related in some way?
The projects that are failing target netstandard 2.0 (The same as the projects that do build). The version returned by dotnet --version on all 3 environments is 2.1.504.
Any help would be greatly appreciated.
You need to use msbuild.exe instead of dotnet
build
for this situation.
msbuild.exe runs on full framework while dotnet buildruns on .NET Core, and most of the build tasks don't support that.
When you build them in VS,it actually calls the msbuild.exe to build the solution.So you can build it well by developer command prompt since it also calls the msbuild.exe.
For vs2017, you can find it in C:\Program Files (x86)\Microsoft Visual Studio\2017\Edition\MSBuild\15.0\Bin.
More details see Martin's answer from this similar issue. Thanks to his detailed description!
I am following the tutorial for .NET on
https://www.microsoft.com/net/learn/get-started/macos
I installed the .NET SDK and create an app by using on macOS High Sierra Version 10.13.5:
~$ dotnet new console -o myApp
which gives me an error of:
The template "Console Application" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on myApp/myApp.csproj...
Unable to load shared library 'libproc' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES
environment variable: dlopen(liblibproc, 1): image not found
I tried to do
export DYLD_PRINT_LIBRARIES=/usr/lib/
before deleting the created folder and files, and I get a lot of printed statements that look like:
dyld: loaded: /usr/local/share/dotnet/shared/Microsoft.NETCore.App/2.1.1/System.IO.Compression.Native.dylib
as well as the same error:
The template "Console Application" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on myApp/myApp.csproj...
Unable to load shared library 'libproc' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES
environment variable: dlopen(liblibproc, 1): image not found
I got it to work by using fs-usage to examine where does dotnet try to find libproc.dylib. In my case, I found that dotnet was trying to find libproc.dylib at ~/libproc.dylib, so I copied /usr/lib/libproc.dylib to ~/libproc.dylib and dotnet worked.
I think this is not a satisfactory answer so if anyone knows why dotnet was not looking for libproc.dylib at /usr/lib/libproc.dylib, please help me out. Thank you!
I noticed that my comment only worked when I started pwsh in ~.
I created a symlink in /usr/local/microsoft/powershell/6 that points to libproc.dylib:
/usr/local/microsoft/powershell/6$ sudo ln -s /usr/lib/libproc.dylib libproc.dylib
PowerShell starts correctly in any directory.
This will likely need to be recreated when I upgrade PowerShell Core (via Homebrew Cask).
** edit **
I should have read the question more closely--it was about dotnet, not pwsh.
I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:
dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].
My project.json looks like this:
{
"buildOptions": {
"warningsAsErrors": true
},
"dependencies": {
"Microsoft.AspNetCore.Razor": "1.0.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"description": "Precompiles Razor views.",
"frameworks": {
"netcoreapp1.0": {
"imports": [ ]
}
},
"version": "1.2.0"
}
What is hostpolicy.dll, and why is it missing?
Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.
It contains:
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
then dotnet.exe exec "path/to/appname.dll" [appargs] works.
This error message is unhelpful. The actual problem is a missing emitEntryPoint property:
"buildOptions": {
...
"emitEntryPoint": true
},
Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.
If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..
There is a Github issue for this and a workaround.
Edit: Should be fixed in .NET SDK 5.0.200.
I had similar problem running tests in VS19.
========== Starting test run ==========
Testhost process exited with error: A fatal error was encountered. The
library 'hostpolicy.dll' required to execute the application was not
found in 'C:\Program Files\dotnet'. Failed to run as a self-contained
app.
After digging into it I found the source of the problem:
The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.
This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).
Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.
I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.
I am having this problem in Dotnet Core 3.1 Console application.
If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.
If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)
I had this happen with .NET 6.0 where somehow the appname.runtimeconfig.dev.json file was not being generated in the bin/Debug/net6.0/ directory.
The fix was modifying the .csproj file and include this fragment inside the <PropertyGroup> element:
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
I found this solution while searching with https://www.google.com/search?q=net60+runtimeconfig.dev.json at Breaking change: runtimeconfig.dev.json file not generated - .NET | Microsoft Learn with the solution at MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn:
GenerateRuntimeConfigDevFile
Starting with the .NET 6 SDK, the [Appname].runtimesettings.dev.json file is no longer generated by default at compile time. If you still want this file to be generated, set the GenerateRuntimeConfigDevFile property to true.
<PropertyGroup>
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
</PropertyGroup>
After applying this to the .csproj file and re-building the project, debugging from Visual Studio Code worked fine including stopping at the breakpoints that I had set previously.
For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.
Once I modified the version in my .json file the application started working fine.
In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.
The failing package was built using:
dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app
Changing the RID:
dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app
produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 😅
Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...
My problem was that I have 2 .NET Core App projects and one is dependent on the other.
(so I can then execute that application from that other application)
But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.
The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:
COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y
But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.
Note that there should be a better more generic way to do this for every .NET Core App Project automatically.
This error is quite generic. So the real problem can be anything.
In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.
A Class Library DLL can't be runned with MSBuild, even if it has a Main method.
Only Console Application DDL can be runned as dotnet <appname>.dll
I was getting similar error while running Unit tests using VSTest#2 task in Azure Devops.
In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.
Below one worked for me.(if you are getting this error with VSTest)
- task: VSTest#2
displayName: 'Running UnitTests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
$(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
$(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
!**\*TestAdapter.dll
!**\obj\**
platform: x64
configuration: Debug
codeCoverageEnabled: true
So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.
I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.
I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.
I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.
(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)
Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)
For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.
For me, the error occurred during the SonarQube coverage scan due to one of the projects had a project reference to a MSTest project.
I faced this problem and it took me couple of days to figure out the solution.
Go to Visual Studio Installer.
Click on 'More' option of the Visual Studio.
Select 'Repair'.
It'll take some time for the download and installation.
Once it's completed restart the machine and try again.
This should solve the issue.
Add the OutputType on the PropertyGroup and issue is solved
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
more about this MSBuild can be found here
In trying to build NuGet3, I'm getting the following error:
~/Projects/NuGet3-dev/src/NuGet.CommandLine/project.json(22,46): error: The dependency fx/Microsoft.Build.Framework >= 14.0.0 could not be resolved.
I have no idea why it wouldn't be resolved, since according to
gacutil -l
I have it:
Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
I looked at everything I could find about this issue, but it's almost entirely Visual Studio and Windows based resolutions, and nothing seems to apply to my situation...
How to make this resolve?
(Assuming you are working on https://github.com/NuGet/NuGet.CommandLine ...)
How to resolve?
Use Windows. This project is not designed to be built on Mono. It is integrated with Windows tooling.
Under POSIX systems (thought, some true operating system):
In short, the dependency is resolved using DNX or dotnet (said M$ .Net Core), and its restore command.
The fx/ stands for framework, just drop the prefix, it should be the same. I sow these kind of notations disappear, when passing to DNX. Just try and install it using the DNX process.
since MSBuild targets and props for DNX are not available, the xbuild script from Mono won't work.
You'll have to use one of
the "deprecated" dnvm.sh script and dnx/dnu commands to restore and then build each sub project.
Note: that yet isn't anymore available at download, and the call to dnvm update-self relaces the script by a "404" ...
The "Microsoft .NET Core Shared Framework Host", "dotnet" (that I don't use)
It should mostly work, if you've got Dnx, try this command line, from the src sub-dir of the NuGet3 source code:
(for d in *; do (cd $d && dnu restore && dnu build); done)2>&1|tee build-all.log
For me, using Debian-8, there are build failures:
NuGet.CommandLine.XPlat
NuGet.Configuration, but it succeeds for the "net451" framework
NuGet.Packaging.Core
NuGet.Packaging
NuGet.Protocol.Core.v3, but it's OK #dnxcore50 (don't ask me why) ...
YANote: If code cannot be transformed anywhere but by M$, this is cannot be source code for me : I cannot not use it as a source. This is a secret code, a private code ... something to throw away, and that probably no one cares.