I'm trying to set up continuous deployment (.NET Core 1.1 Web Application) with the build mechanism of VSTS.
To do so I'm following the steps displayed on the official doc of Microsoft :
Use VSTS to Build and Publish to an Azure Web App with Continuous Deployment.
The first 3 steps (restore/publish/zip) work without any issue. But the fourth step is failing. I'm not able to publish the app to my Azure App Service.
Here is the error (from the log) :
2016-12-22T14:12:13.1175907Z Got connection details for azureRM WebApp:'devoteamlogin-staging'
2016-12-22T14:12:13.5419583Z Running command: "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:getParameters -source:package="C:\a\1\a\DevoteamLogin.zip" > "C:\a\1\s\parameter.xml"
2016-12-22T14:12:14.8449274Z Error Code: ERROR_EXCEPTION_WHILE_CREATING_OBJECT
2016-12-22T14:12:14.8449274Z More Information: Object of type 'package' and path 'C:\a\1\a\DevoteamLogin.zip' cannot be created. Learn more at:
2016-12-22T14:12:14.8449274Z Error: The Zip package 'C:\a\1\a\DevoteamLogin.zip' could not be loaded.
2016-12-22T14:12:14.8449274Z Error: Package file 'C:\a\1\a\DevoteamLogin.zip' is not in a supported .zip format and therefore cannot be read.
2016-12-22T14:12:14.8449274Z Error count: 1.
2016-12-22T14:12:14.8509276Z ##[error]TypeError: Cannot read property 'output' of null
2016-12-22T14:12:14.8589281Z ##[section]Finishing: Deploy AzureRM App Service: devoteamlogin-staging
Step details
Am I missing something somewhere ? I did exactly what the documentation says (same variables, same steps, same configuration).
Update: After making some new tests, I see that the 'dotnet restore' command does not restore anything because it does not find the project.json. But there is no project.json file anymore in the new ASP.NET Core 1.1 Web application (everything is in the .csproj file).
warn : The folder 'C:\a\1\s' does not contain a project to restore.
Here is a solution https://twitter.com/DonovanBrown/status/816380372028002304. This shows the requirements to build csproj projects with Team Services. It is a full working solution.
I think the format of your zip archive is wrong, I used the native archive file task instead and unchecked "Prefix root folder name to archive paths".
Also I followed the documentation from the Visual Studio Team instead of the one from the dotnetcore team. It works better I found.
Related
I have recently upgraded my .Netcore webapi from 2.2 to 3.1 and deployed to azure app services.
Since then I got the below issue. I have reverted the release but still getting the same error.
I found few solutions for IIS but nothing for Azure app services .How to fix this?
[NEWEST]
Solution:
Reduce the version of Microsoft.Extensions.Configuration.Abstractions to 3.1.17 or 3.1.16.
Troubleshooting:
Try to find Microsoft.Extensions.Configuration.Abstractions on scm site.
I guess it don't include Microsoft.Extensions.Configuration.Abstractions package when deploy, so try to use below code in .csproj file. But it failed.
I try to find the reason on scm site, and I find it. On azure, .net core 3.1 just support the version of Microsoft.Extensions.Configuration.Abstractions are 3.1.17 and 3.1.16.
[PREVIOUS] The way to find the error logs
Judging from the error message, your webapp did not start. To solve the problem, we can only locate the error by querying the log.
You have the following two solutions to solve the problem. View the log:
Prerequisite: If you have successfully deployed the project before, please log in to the scm site to clean up all the files in the original wwwroot folder.
Plan 1:
Find the web.config file in the wwwroot folder and set stdoutLogEnabled="true".
You can refer to the following posts and github issues.
Azure Web App - Python: can't open file 'manage.py': [Errno 0] No error
How to enable stdoutLogEnabled=true when site is deployed with Run From Package
After add the settings in web.config, we can check the logs.
Plan 2:
Follow below picture, check Application Event Logs.
You also can refer my answer to Collect .NET Profiler Trace (Azure - Unhandled Exception: System.IO.FileNotFoundException).
After find the error, you can solve it quickly. If you also have some problem, you can create a new project without any sensitive info for us to reproduce your issues.
I'm trying to deploy my F# ASP.NET Core app to Azure App Service. Unfortunately, each time I try to deploy, a <UserSecretsId> element is added to my project file, which as explained in this article causes the build to fail with the following error:
A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence
The article explains why the error occurs and instructs to fix it by removing the element from the project file and instead adding the user secrets ID in an AssemblyInfo.fs. I have tried this and can then build manually, but each time I try to deploy, the deployment process still adds a <UserSecretsId> element with a new ID in my project file, causing the build to fail.
Is there any way I can publish an F# ASP.NET Core app to Azure App Service?
(Also reported on Microsoft/visualfsharp#5549)
Add this to your .fsproj file to suppress the attribute generation.
<PropertyGroup>
<GenerateUserSecretsAttribute>false</GenerateUserSecretsAttribute>
</PropertyGroup>
If you want to use user secrets, you will manually need to add the UserSecrets assembly attribute.
module Your.Namespace.AssemblyInfo
open Microsoft.Extensions.Configuration.UserSecrets
[<assembly: UserSecretsIdAttribute("Your UserSecretsId")>]
do()
Also, this workaround should be unnecessary in ASP.NET Core 2.2. See https://github.com/aspnet/Configuration/pull/872
I've created a web job using the webjobs sdk that is linked to my web application. Well it isn't anymore (I removed the webjobs-list.json file from the web app project), because when it was linked, it just copied the source code files into the websites' app-data folder, not the bin folder/binaries/exe. But now that my web job is deployed from visual studio online to azure with my website, and tries to run, it's not reading the connection strings (AzureWebJobsStorage and AzureWebJobsDashboard) from the connection strings in my web application's settings in the azure portal. It looks for them in the config file that is deployed with the exe that is generated from compiling the webjob. If I manually put those strings in that config and check in, and redploy it will use them from there, so it's not checking the portal at all (even though my web app is running fine using what is defined in the portal). I thought that all web jobs were supposed to look for connection strings in the azure portal first? That isn't happening at all for me. Has anyone else experienced this? Could it have something to do with how it's deployed by visual studio online?
Part of the error getting logged for the webjob process when trying to start:
Microsoft.Azure.WebJobs.Host.Indexers.FunctionIndexingException: Error indexing method 'Functions.ProcessTestQueueMessage' ---> System.InvalidOperationException: Microsoft Azure WebJobs SDK 'Storage' connection string is missing or empty. The Microsoft Azure Storage account connection string can be set in the following ways:
[04/01/2017 02:27:40 > ceef22: INFO] 1. Set the connection string named 'AzureWebJobsStorage' in the connectionStrings section of the .config file in the following format , or
[04/01/2017 02:27:40 > ceef22: INFO] 2. Set the environment variable named 'AzureWebJobsStorage', or
[04/01/2017 02:27:40 > ceef22: INFO] 3. Set corresponding property of JobHostConfiguration.
[04/01/2017 02:27:40 > ceef22: INFO] at Microsoft.Azure.WebJobs.Host.Executors.StorageAccountParser.ParseAccount(String connectionString, String connectionStringName, IServiceProvider services)
Also, the only way I could get this to really deploy was to remove the webjobs-list.json file from the properties folder in the web project. I know I'm not supposed to do that, that everything should just work and deploy with that in there, but when I left it in there, it wouldn't copy the binaries/bin/executable files into the App_Data\Jobs\continuous[webjob] folder on the website...it would literally copy all of the source code\files for the web job project into there (which of course wouldn't work/run, since it's just code, not an exe). After removing that webjobs-list.json file, and then adding a second task to my release to find the [webjob].zip file from the build, then it would copy just the binaries and executable into the App_Data\Jobs\continuous[webjob] folder. Maybe this is just an issue with trying to build and release from visual studio online, and it doesn't handle web job deployment well...not sure, I haven't been able to find a lot of information on setting that up to deploy a web job with a web app.
Normally, this should just work. The flow is:
The WebJobs exe doesn't run in-place, but first gets copied to a temp folder
As part of that copying process, if any of the AppSettings & Conn Strings in the foo.exe.config file are set as Azure settings, they get replaced (only in the temp copy, not under App_Data).
Can you make sure that you are deploying both your foo.exe and foo.exe.config?
Update: as we found on chat, the problem was that you had a typo in the name of the connection string in Azure.
The project was generated through Ionide and Visual Studio Code. I'm deploying to an Azure WebApp through GitHub.
The GitHub repository is: https://github.com/laygr/suave-dummy
The activity log says:
Command: build.cmd
The system cannot find the path specified.
�
The system cannot find the path specified.
D:\Program Files (x86)\SiteExtensions\Kudu\59.51109.2534\bin\Scripts\starter.cmd build.cmd
It is as simple as a Suave app gets. I hope that this can help others.
Edit
After restarting fresh again (new repo, new web app, new day, new hopes), azure showed a different error which allowed me to figure out the rest. I'll leave the repo so that anyone can see how to deploy the simplest Suave app as an Azure Web App through GitHub
So, after an improvement on the error shown by Azure, I could figure out how to deploy the app.
I had to:
remove .exe from the .gitignore generated by Ionide for Visual Studio Code.
create .deployment
create web.config
modify the build.cmd (I copied it from somewhere else)
modify the build.fsx to perform the correct build
modify the startup file (suave-dummy.fs) to use the correct port
Feel free to check the repo to see what I mean in code. Relevant files:
.gitignore
.deployment
suave-dummy\WebHost\web.config
build.cmd
build.fsx
suave-dummy\suave-dummy.fs
phew!
A website with webjob not deploying to Azure.
I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.
The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.
The solution will build and work locally fine.
The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.
However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!
If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.
It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.
I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.
I have been battling this for a couple of days now an I'm a bit stumped!
This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.
I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.
You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set
That's the root case of problem.
You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.
I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)
So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.
See this