We use automatic deployment process in Azure by KUDU scripts and by today we see strange error in Azure deployment center:
Command dotnet publish (and also 'dotnet build') returns:
MSBUILD : error MSB1025: An internal failure occurred while running MSBuild.
Unhandled exception. System.ComponentModel.Win32Exception (5): Access is denied.
System.ComponentModel.Win32Exception (5): Access is denied.
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
at Microsoft.Build.CommandLine.MSBuildApp.Main(String[] args)
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
Failed exitCode=-532462766, command=dotnet publish "D:\home\site\repository\
...
Details:
there is automatic deployment process by KUDU script
app is .NET Core application, .csproj has target framework: netcoreapp2.2
Issue probably will be on Azure side, because we did't do any bigger change in the project.
Has anybody same/similar issue?
We had the same issue and after investigation we found that:
Azure applied new 'dotnet' version 3.1.301 and this version of SDK throws that error (your version you can check by commnad 'dotnet --version')
by command 'dotnet --list-sdks' you can see all installed SDKs
then we simple used previous version (in our case v3.1.202)
the easiest way how to tell exact version of dotnet sdk is by global.json
Example:
global.json
{
"sdk": {
"version": "3.1.202"
}
}
And file must be in 'working directory', and KUDU script has working directory here D:\home\site\repository
When your deployment was OK on previous version of dotnet SDK, than this should definitely help.
This problem could also happen in other situations because of the sdk is installed as admin (e.g if installed with sudo).
In this case uninstalling the sdk and installing it as non-admin user could help resolve the issue. You can use this script to install for non-admin user.
e.g (tested on ubuntu 20.04):
$ wget https://dot.net/v1/dotnet-install.sh
$ chmod +x dotnet-install.sh
$ ./dotnet-install.sh -c Current
Add to the path and verify:
$ echo "export PATH=$HOME/.dotnet:$PATH" >> ~/.bashrc
$ exec bash
$ dotnet --version
3.1.402
NB: After doing this you may get an error error : Unable to obtain lock file access on '/tmp/NuGetScratch/lock then you could remove it and good to go.
sudo rm -r /tmp/NuGet*
Related
Running into a total dead-end here.
I've created a Publish Profile for a .net6 application that we want to publish to IIS with Web Deploy. In the Entity Framework Migration section, the option to "Apply this migration on publish" is selected.
When manually clicking publish, everything works. However, we want to automate this in TeamCity using the .NET build runner. The publish step fails at:
Generating Entity Framework SQL Scripts...
Executing command: dotnet ef migrations script --no-build --idempotent --configuration Release --output "C:\TeamCity\buildAgent\work\cbf95cc2b4413601\MySolution.Api\obj\Release\net6.0\PubTmp\EFSQLScripts\MySolution.Data.MyContext.sql" --context MySolution.Data.MyContext
C:\Program Files\dotnet\sdk\6.0.400\Sdks\Microsoft.NET.Sdk.Publish\targets\TransformTargets\Microsoft.NET.Sdk.Publish.TransformFiles.targets(221,5): error : Entity Framework SQL Script generation failed
Internal error message details: BuildMessage1 0 Text DefaultMessage ERROR 400682522803500 tags:'tc:parseServiceMessagesInside'
Error message is logged
Build FAILED.
I cannot find any specific error messages anywhere in any log. Looking in the Microsoft.NET.Sdk.Publish.TransformFiles.targets file shows that it's failing on GenerateEFSQLScripts - an MSBuild command that executes dotnet ef under the covers.
I thought this might be a case of dotnet ef not being installed on the build agent. But when I manually run the command myself from C:\TeamCity\buildAgent\work\cbf95cc2b4413601\MySolution.Api, it succeeds, and the SQL scripts are successfully created.
I also thought it might just be a case of the command being run in the wrong directory (i.e. in the root MySolution folder rather than the MySolution.Api folder), but explicitly setting the working directly fails at the same point, with the same error.
Has anyone seen this before? Or could point me to where an actual error might be located?
I have Asp.net core Xunit integration tests that connect to MongoDb to test basic repositories on collections. The tests are built and run in a container in AKS. I have setup the test fixture to connect Azure Key Vault to retrieve connection string to a MongoDb.
var pathToSetting= Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var configuration = new ConfigurationBuilder()
.SetBasePath(pathToSetting)
.AddJsonFile("appsettings.json")
.AddEnvironmentVariables();
var secretClient = new SecretClient(
new Uri("url_to_Azure_keyVault"),
new DefaultAzureCredential(),
new SecretClientOptions()
{
Retry =
{
Delay = TimeSpan.FromSeconds(2),
MaxDelay = TimeSpan.FromSeconds(4),
MaxRetries = 2,
Mode = RetryMode.Exponential
}
});
configuration.AddAzureKeyVault(secretClient, new KeyVaultSecretManager());
I am using the following Docker file for the integration tests:
#Grab an OS image made to run the .Net Core SDK
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
#copy files for build
WORKDIR /testProject
COPY . .
RUN dotnet build tests/integrationTest.csproj --output /testProject/artifacts
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS final
COPY --from=build ["/testProject/artifacts", "/testProject/artifacts"]
ENTRYPOINT dotnet test /testProject/artifacts/integrationTest.dll
The tests run fine locally from Visual Studio but fail with exception below when run in container both locally and in AKS.
[xUnit.net 00:00:03.10] IntegrationTest1 [FAIL]X
Test1 [1ms]
Error Message:
System.AggregateException : One or more errors occurred. (SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details) (The following constructor parameters did not have matching fixture data: TestFixture testFixture)
---- Azure.Identity.AuthenticationFailedException : SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details
-------- Microsoft.Identity.Client.Extensions.Msal.MsalCachePersistenceException : Persistence check failed. Inspect inner exception for details
------------ System.DllNotFoundException : Unable to load shared library 'libsecret-1.so.0' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment
variable: liblibsecret-1.so.0: cannot open shared object file: No such file or directory
Any ideas how to troubleshoot this error ?
I came across this potential fix while working on my own issue:
Wherever you create new DefaultAzureCredentialOptions, you should also set the property ExcludeSharedTokenCacheCredential to true.
In your WSL environment install libsecret-1-dev. In Ubuntu for example, run the command sudo apt install libsecret-1-dev. This will add libsecret-1.so.0 to your system so that MSAL can find it.
https://hungyi.net/posts/wsl2-msal-extensions/
It didn't work for me, but I am using a docker container that doesn't have full access to apt. I can't install libsecret-1-dev.
Not a root cause, but same error popped up for me this morning. Rolling Microsoft.Web.Identity package down from 1.7.0 to 1.6.0 did the trick.
Looks like from the GitHub issues on other Azure packages, wrapping these exceptions is a common bug that gets logged.
Switching Azure.Identity 1.2.3 to 1.2.2 did the trick for me (this page helped me https://hungyi.net/posts/wsl2-msal-extensions/).
I had a operating bot that I tried to push an update to and got a failure response. I tried building and deploying in Kudu with no luck either. Just as a sanity check I also made a brand new echobot on Azure and tried to run the build and deploy commands in Kudu Console.
EDIT: Meant to mention I've seen a few other mentions of similar issues including:
Error - Access is denied - deployment to Azure App Services
https://github.com/projectkudu/kudu/issues/3177
https://medium.com/rare-crew/hot-issue-on-azure-and-deployment-of-apps-by-kudu-scripts-dotnet-sdk-v3-1-301-92d6e336756a
MSBUILD : error MSB1025:Unhandled exception. An internal failure occurred while running MSBuild.
System.ComponentModel.Win32Exception (5): Access is denied.
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
System.ComponentModel.Win32Exception (5): Access is denied.
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
at Microsoft.Build.CommandLine.MSBuildApp.Main(String[] args)
Failed exitCode=-532462766, command=dotnet restore "EchoBot.sln"
An error has occurred during web site deployment.
We arrived at an answer in this thread: Microsoft Help Link
For the default Echobot project generated by Azure you need a global.json file in "D:\home\site\wwwroot" with the following code. You can get to this folder by using the Kudu debug console.
{
"sdk": {
"version": "3.1.202"
}
}
The issue is recently introduced by latest dotnet sdk (2.1.515 and 3.1.301) versions. This impacts the projects with custom deployment script still using dotnet restore and publish to build.Could you please try the below workaround in deploy.cmd to fix it.
SET MSBUILD_PATH=%ProgramFiles(x86)%\MSBuild-16.4\MSBuild\Current\Bin\MSBuild.exe
call :ExecuteCmd "%MSBUILD_PATH%" -t:Restore "%DEPLOYMENT_SOURCE%\my-solution.sln"
call :ExecuteCmd "%MSBUILD_PATH%" -t:Publish "%DEPLOYMENT_SOURCE%\vstar-next\my-proj.csproj" -p:OutputPath="%DEPLOYMENT_TEMP%" -p:Configuration=Dev
I am used to publish Azure WebApps on Windows but now I am trying to deploy an ASP.NET Core 3 (with NodeServices) to a Linux WebApp and I am receiving the following error message:
InvalidOperationException: Failed to start Node process. To resolve this:.
[1] Ensure that Node.js is installed and can be found in one of the PATH directories.
Current PATH enviroment variable is: /opt/dotnetcore-tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/site/wwwroot
Make sure the Node executable is in one of those directories, or update your PATH.
On Windows WebApps I have a lot of other apps and all are fine.
On Kudu I typed node -v and the output was v12.13.0.
Can anybody please help me?
Thank you very much.
After a long research and the assistance of Microsoft's Engineer https://github.com/caroe2014 this is the three steps final answer:
1) Startup.cs
services.AddNodeServices(options =>
{
if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
options.ProjectPath = Path.GetFullPath("/home/site/wwwroot");
}
}
);
2) And what I found is Node is not present in the container so it is necessary to have a script to install and start it before starting the app itself. So I have this start1.cs file:
#!/bin/bash
apt-get install curl
curl -sL https://deb.nodesource.com/setup_12.x | bash
apt-get install -y nodejs
set -e
export PORT=8080
export ASPNETCORE_URLS=http://*:$PORT
dotnet "Web.Identity.dll"
Where Web.Identity.dll is the dll of my app.
3) Set startup command to /home/site/wwwroot/start1.sh (On Azure Portal - App service Configuration - or Azure DevOps).
That's all.
Try to mention the path in the code, This is how NodeServices was configured in Startup.cs:
services.AddNodeServices(options =>
{
options.ProjectPath = "Path\That\Doesnt\Exist";
});
I followed this article to setup a performant ASP.NET Core deployment using Docker. This works until I try to start the container using docker run which calls dotnet MyAppName.dll There I got an exception, that the View path is not existing:
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: The directory name /app/Views/ is invalid.
And thats true, cause in the folder created by dotnet publish area only dll files and no View folder:
user#server:/etc/jenkins/workspace/App# ll publish-output | grep View
-rwxr--r-- 1 root root 237K Aug 31 19:26 Microsoft.AspNetCore.Mvc.ViewFeatures.dll
I cant understand this, cause the View folder is included in the publishOptions like wwwroot too, which is also missing:
"publishOptions": {
"include": [
"wwwroot",
"Views/**/*.cshtml",
"Areas/**/*.cshtml"
]
},
I also tried "Views" instead of "Views/**/*.cshtml" but not working. In my understanding, those publishOptions should result in copying those folders to the publishing-directory when using dotnet publish.
What am I doing wrong?
I'm using the microsoft/aspnetcore-build:1.0.1 image for building and microsoft/aspnetcore:1.0.1 for starting the app like recommended as best practice in the article.
UPDATE
Seems to be a problem on linux only. My Win10 development machine works fine, there I get any view-folders published from the main app and areas as expected.
UPDATE #2 Using the examples on the aspnetcore-build repo on the docker hub, its not working too.
UPDATE #3 I created a new ASP.NET Core MVC project on my Windows 10 development machine using Visual Studio, then transferred it to the linux box: Not working, the views are missing.
UPDATE #4 Created a new app using dotnet new -t web directly on the linux box: Works like expected!
UPDATE #5 I ran dotnet new -t web on the Windows machine, moved the created folder to the linux server: Not working - Strange...
The problem was a missing space in the documentation before the dot, which should refer the current folder.
Wrong (1:1 copy from the description of the docker image)
RUN dotnet publish --output /out/. --configuration Release
Correct
RUN dotnet publish --output /out/ . --configuration Release
Here is the space missing: --output /out/{Space}.