At work I'm using Visual Studios 2019 to publish my ASP.Net Core 2.1 App to the Azure App Service. At home I run a linux maschine and use VS Code to work on the project. Now I'm having trouble to deploy the app to Azure using 'Deploy to Web App' in VS Code. The process finishes successfully but when I open the url I get an 'IIS 502.5 Error - Process Failure'. Using Visual Studio this does not happen.
Before deploying the app I tried to build it using
dotnet build -c Release
with no success. I also tried
dotnet publish -c Release -f netcoreapp2.1 --no-self-contained
with no success too. Both commands followed by 'Deploy to Web App'.
Am I doing something wrong or do I miss some build-option?
Got it myself. Found the solution here.
You just have to set the deploySubpath to the directory where dotnet publish puts the generated files. In my case I had to set it to project_1/bin/Release/netcoreapp2.1/publish, which will be created by the command dotnet publish -c Release.
You can set the deploySubpath value in Settings > Extensions > Azure App Service or by editing the file settings.json in the .vscode directory. This directory will be created in the root directory of your workspace.
Be careful to always set the deploySubpath relatively to your .vscode directory. In my case my workspace looks like this
-- .vscode
:- project_1
`- project_2
where project_1 is my ASP.Net Core project and project_2 is a nodejs project.
Related
I have a .NET 7.0 blazor wasm app, that I deploy to a windows server running IIS. This has worked fine, until i added the following to my project (The client, and the project is .net core hosted):
<WasmEnableSIMD>true</WasmEnableSIMD>
<RunAOTCompilation>true</RunAOTCompilation>
First i got the following error in my build pipeline:
error NETSDK1147: To install these workloads, run the following command: dotnet workload restore
So i added a command line step to my build pipeline where i run the following command:
dotnet workload restore
So far so good. Now the project builds again. But my release now fails. I have 3 steps in my release pipeline for my IIS server:
Stop app pool
deploy my app
start my app pool
This worked fine before adding the two statements above. But now i get the following error:
Failed to deploy web package to IIS website.
Error: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-".
Error count: 1.
Error: The process 'C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe' failed
with exit code 4294967295
I can't seem to find a solution, so has anyone tried something similar?
Apparently i wasn't the only one with the issue:
https://github.com/microsoft/azure-pipelines-tasks/issues/17634
I ended up removing web deploy 4.0, and now it works again.
Maybe if I had waited longer, i wouldn't have to remove web deploy 4.0
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 am deploying my ASP .Net Core 2.0 app to my remote server using FTP. Remote Server is using IIS 8. When I publish my app, I get the following error.
Unable to add 'Project.dll' to the Web site. The process cannot access the file because it is being used by another process (550).
I been able to bypass this by manually creating an app_offline.htm first on the publish directory, and then publishing my app via Visual Studio 2017.
I was wondering, is there an easier way of doing this? or is there an easy way I can script this, so that app_offline gets created automatically before publish? and then deleted after publish?
Anyone that's curious, I gave up depending on VS to publish my .NET Core project. I'm now using WinSCP and _PublishToWeb.bat script I created to accomplish the task.
I first created a file called _app.offline.htm on root directory my publish folder. Then when I need to publish, I run the script below.
This script does the following:
1. Builds the .NET Core project to a specific folder, let's call it "_dist" folder.
2. Connects to my ftp server/publish folder and renames "_app_offline.html" to "app_offline.html", so that the server goes offline.
3. Synchronizes _dist folder with publish folder.
4. When done, changes "app_offline.htm" to "_app_offline.html", so the website is restarted.
_PublishToWeb.bat
echo off
echo Publishing to ProjectName (Optional)
set ProjectRemoteFolder=RemoteFolderName
set ConnectionString=ftp://username:password#serverIp:serverPort
set WinSCP="path to WinSCP.com"
set ProjectDistPath="a folder where dotnet publish will build the project to"
set WebAppProject="path of the project. dotnet publish will run here"
rem Build project and put it in to distribution folder
cd %WebAppProject%
dotnet publish -c Release -o %ProjectDistPath%
rem Connect to FTP and synchronize folder
%WinSCP% /command "open %ConnectionString%/%ProjectRemoteFolder%/" "mv _app_offline.htm app_offline.htm" "synchronize remote %ProjectDistPath%" "mv app_offline.htm _app_offline.htm" "exit"
rem pause
I'm sure there are better solutions out there, but this has been working well for me so far.
I just upgrading my Azure service from free level to basic level to get more file storage space. But now accessing my first newly deployed Web app shows: "You do not have permission to view this directory or page." The deployment from Bitbucket worked. The kudu console shows everything loaded. I have 3 branches in my repo and three Azure apps defined, one for each. Two were deployed before upgrading and they are okay. The third was just deployed after the upgrade and has this problem. All three come from the same repo, and at this time all three branches are basically the same. All are the same basic ASP.NET Core 1.0 web app for each branch. I checked a lot of google pages, but none were helpful. Where do I go to fix this?
This just means that the website didn't load so the IIS server is falling back and trying to load one of the html files it has in the list for startup which you wouldn't have since it should be loading up your site code instead, the directory listing is the last thing it could show and will fail in this scenario. Pay special attention to any differences in the deployment methods or any changes made to the Startup.cs file.
Your application files may not have deployed correctly. The root / gave me:
You do not have permission to view this directory or page.
When I tried a static HTML file I got:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
(This should have been served by the .NET Core static middleware.)
I'd been playing with my Azure Pipelines YAML and it was pushing the wrong files up in the deploy to Azure Web App task step, thing.
My app is .NET Core 2.2 in "Run-from-Zip" mode, now called Run-from-Package.
A path error in my YAML meant the package contained another subfolder with the package inside it, instead of it all being in the root of the package, if that makes sense.
Maybe this fascinating story helps someone.
A frustrating experience making this work caused me to write this guide. What happens is your output may be missing some of the files needed, or be structured incorrectly, for IIS to launch your app. The issue can arise for different reasons.
Archive contains root directory.
When you create your zip file, make sure you are not archiving the root folder. What happens is your /home/site/wwwroot directory looks like:
/home/site/wwwroot
--RootFolder
--LaunchFile
When IIS is expecting
/home/site/wwwroot
--LaunchFile
This is easy to fix by adding includeRootFolder: false to the ArchiveFiles#2 task.
- task: ArchiveFiles#2
displayName: 'Archive files'
inputs:
includeRootFolder: false
Alternatively, if using the Web UI in the Root folder or file to archive section ensure that
Prepend root folder name to archive paths is not checked.
Build vs Publish
Using the .NET Core task to build the project or solution can result in output that will not work in the /home/site/wwwroot directory. The key here is to choose the publish option, not the build option. build was working for us and then did not for one of our projects. Changing to publish made it work again.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'MyProj/MyProj.csproj'
arguments: '--output $(Build.BinariesDirectory)/WhereYouWantFilesForNextStep --configuration Release'
Instead, use the publish command.
steps:
- task: DotNetCoreCLI#2
inputs:
command: publish
arguments: '--configuration Release -o $(Build.BinariesDirectory)/WhereYouWantFilesForNextStep'
Zip File is not Mounted
Zip archives deployed to Azure are stored in
Directory of D:\home\data\SitePackages
11/03/2021 06:24 PM <DIR> .
11/03/2021 06:24 PM <DIR> ..
11/03/2021 04:24 PM 66,278,978 20211103162437.zip
11/03/2021 06:24 PM 73,799,022 20211103182443.zip
11/03/2021 06:24 PM 18 packagename.txt
And, if the following Application Setting is provided:
WEBSITE_RUN_FROM_PACKAGE = 1
Then IIS will mount the zip archive specified in packagename.txt to the D:\home\site\wwwroot.
D:\home\data\SitePackages>cat packagename.txt
20211103182443.zip
Note that 20211103182443.zip is the name of one of the .zip file listed in D:\home\data\SitePackages directory. Now if WEBSITE_RUN_FROM_PACKAGE is toggled the contents of D:\home\site\wwwroot will change.
Useful Resources
Additional reading is available at Microsoft Docs: Run your app in Azure App Service directly from a ZIP package.
If you want to examine the contents of the zip file directly, PowerShell will work in the console provided at App Service > Development Tools > Console and has access to the Unzip command.
D:\home\data\SitePackages>PowerShell Unzip -l 20211103162437.zip
Archive: 20211103162437.zip
Length Date Time Name
--------- ---------- ----- ----
25600 2013-07-17 23:18 AForge.Genetic.dll
...
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}.