I created a sample project from template asp core web application in VS2019.
Local build works fine.
I have a repo in Bitbucket which I connected to azure app service through deployment center and I pushed sample project to that repo.
Project gets properly noticed and built. Deployment has status successful, but opening it shows that bootstrap and jquery cannot be found. Scm shows, that they were not published:
What do I have to do/set to properly set up push/build/deployment sequence?
Note: code that loads bootstrap and jquery is not conditional - it doesn't depend on environment
Please check your csproj file and verify if they are not getting excluded.
I had a similiar issue recently, I had to manually remove the excludes and added the below to my csproj file to make it work.
<ItemGroup>
<None Include="wwwroot\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
Related
There are very good instructions on how to automate Web App deployment - both creating the required infrastructure and deploying the web app contents.
For example, this is very well described here
However, I can't find any detailed instructions on how this is done for a Function App.
What is my case:
I'm using Azure RM Template deployments with a Visual Studio 2017 Resource Group project
I have successfully defined the Function Template
I have successfully defined the Web Deploy Template for the function
I have created my Function as a separate project and it is working correctly
On the Resource Group project, a reference to the Function project has been added and its properties defined as follows:
When I deploy the Resource Group it fails with the message "The target "Package" does not exist in the project."
This means that it cannot build the ZIP package.
Everything is working fine if I remove the "Package" parameter from "Include Targets" and then manually supply the "package.zip" to the Resource Group project.
How should the Resource Group project be configured in order to be able to self-build the ZIP package for the Function App project?
Is it possible to add a "Package" target in the Function app project?
Many thanks!
I managed to find a workaround which actually is quite elegant and pretty simple. Hopefully, this will help others:
1. Install "MSBuildTasks" NuGet package on the Function App project
2. Open to edit the .csproj file of the Function App project and add the following somewhere within the <Project> element:
<Project>
...
<Import Project="$(ProjectDir)obj\FunctionApp.csproj.nuget.g.targets" />
<ItemGroup>
<ProjectFiles Include="$(OutDir)\**\*.*" />
</ItemGroup>
<Target Name="Package">
<Zip Files="#(ProjectFiles)" WorkingDirectory="$(OutDir)" ZipFileName="$(PackageLocation)" />
</Target>
</Project>
The important parts in the upper snippet are the following. They help bind the Target to the Resource Group project (see the image in the Question):
the name of the Target should be "Package", which is called by the Resource Group Project
the usage of the $(PackageLocation) property which is passed by the Resource Group Project
This blog post helped me.
You’ll put yourself in a much better position if you embrace Azure Devops up front and automate this process using a CI/CD pipeline.
I’ve done a number of these in the past by breaking up the deployment into three steps (my projects tend to have a logic app which calls the function):
Have an ARM template which contains all the resource group contents other than the logic app. Deploy it first using a resource group deployment task
Use an app service deployment task to publish the zip file generated during the build process. This creates the function app endpoint which would need to exist before the logic app can be deployed
Deploy the logic app from a separate ARM template using another resource group deployment step
I know the logic app piece is outside of the scope you’ve defined in your question, so in your case you’d just leave out the third step.
Even with just a simple function app deployment I’d still make the argument that having a CI/CD pipeline will make your life easier in the long run.
Kloud blog just added a great write up of how to do this.
Building on Vladislav's very help full answer...
A bug in MSBuildTasks nuget deployment prevents it from installing as documented at the project site for .Net Core projects. The .build folder never gets created.
If you add MSBuildTasks, version 1.4.0.128 to a .Net Framework project in the solution, you can use the Import as described on the site:
<PropertyGroup>
<MSBuildCommunityTasksPath>$(SolutionDir)\.build</MSBuildCommunityTasksPath>
</PropertyGroup>
<Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets" />
I have an app service in Azure and I have connected it with my source control on GitLab, everything works fine except one thing. When I deploy from Visual Studio I can tell that App_Data should not be replaced and it works. However, deploying from GitLab (I used this tutorial https://christianliebel.com/2016/05/auto-deploying-to-azure-app-services-from-gitlab/) just replaces all the files with what I have in source control, effectively removing customers data from App_Data.
I presume that this is just simple FTP replace (as I have to run my migrations on App_Start), yet is there a way how to not replace App_Data folder on the app service when deploying from gitlab? Having synchronized App_Data with source control is not acceptable.
Thank you
I have resolved the issue by downloading deployment.zip from AppService's Kudu.
Then I edited downloaded deployment.cmd so that KuduSync ignores App_Data.
Then I inserted the modified deployment.cmd and .deployment file to the root of my git folder.
I have a large number of Azure WebJobs that all deploy to a single Azure App Service, along with a Website on the same Azure App Service. Each WebJob all use the WebJobs SDK and the Microsoft.Web.WebJobs.Publish nuget package (we are up-to-date with version 1.0.13) to package them up for deployment. The following are the MSBuild arguments we use in the CI build (VSTS) to produce the deploy package:
/p:DeployOnBuild=true /p:PublishProfile=Release /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(Build.StagingDirectory)
This produces a package that works fine (in that the WebJobs run correctly as WebJobs) with the "Azure Web Service Deploy" VSTS task, that isn't the problem.
The problem is that the .zip file package duplicates all the WebJob assemblies. These duplicates end up making it out to the Azure App Service.
The folder structure in each WebJob package's .zip file is:
- Content/[build agent full path]/
- app_data/jobs/continuous/[web job name]/[assembly files]
- bin/[assembly files]
This causes a problem for 3 reasons:
We've started investigating partnering with a security vendor who will perform static analysis our our deployment packages. This duplication causes reporting issues.
Because the bin/[assembly files] makes it out to the App Service, they get inter-mixed with the assemblies for the Website that is also deployed to the same App Service.
Our build / release time is slowed down by transferring all this extra bloat in these deployment packages. My team practices Continuous Delivery and expects the pipeline to be fast.
So why does the Microsoft.Web.WebJobs.Publish package add in the bin/[assembly files] in addition to the required app_data/jobs/continuous/[WebJobName]/[assembly files]? And more importantly, how can I prevent the packaging process from including bin/[assembly files]?
I'd really hate to have to add build steps to piece apart the zipped packages and put it back together without the extra junk, or have to figure out a way to hand-craft the publish package. You have 1 job, Microsoft.Web.WebJobs.Publish! :)
My update to https://stackoverflow.com/a/44611520/8654143
I had to add more than one override for existing targets to make it work:
<Target Name="CollectFilesFromContent" />
<Target Name="CollectFilesFromReference" />
<Target Name="CollectFilesFromIntermediateAssembly" />
<Target Name="CollectFilesFrom_SourceItemsToCopyToOutputDirectory" />
How to find it?
1) Run msbuild with /verbosity:diag
2) Inspect the log and look for DestinationRelativePath=bin; there will be related entry FromTarget=SomeTargetName
3) Add <Target Name="SomeTargetName" /> to your .csproj
You should end with entries marked with FromTarget=PublishWebJob.
I think it is possible to filter contents of FilesForPackagingFromProject variable somehow (probably override CustomCollectFiles target and modify FilesForPackagingFromProject there) but I don't know msbuild good enough.
Sorry to hear that you are running into this issue. As a temporary work-around you can override this target(CollectFilesFromIntermediateAssembly) in the csproj. This will stop the files from getting published to the bin folder.
Sample here:
https://github.com/vijayrkn/ASPNetPublishSamples/blob/master/WebJobFullFramework/WebJobFullFramework.csproj#L56-L57
We will fix this issue in the WebJobs.Publish NuGet package soon.
I use VS 2012 and Teamcity with Visual Studio Runner type.
My solution has multiple web.config transformation for different environment.
I want to follow continuous delivery, build the solution with multiple packages and using artifacts deploy them to relevant environment when needed without building again.
I don't use MSBuild directly, I use VS package profiles (pubxml)
I would like to have something like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>Package</WebPublishMethod>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<DesktopBuildPackageLocation />
<PackageAsSingleFile>true</PackageAsSingleFile>
<DeployIisAppPath/>
<PublishDatabaseSettings/>
</PropertyGroup>
<ItemGroup>
<LastUsedBuildConfiguration Include="UAT" />
<LastUsedBuildConfiguration Include="APCI" />
</ItemGroup> </Project>
Then I expect the result be two folders in obj of artifact each with their own transformed web.config.
Any help?
The only way you can create multiple transformed configurations in a single build is by using the XDT engine directly during your build process. It's been available on NuGet for a while now, so it shouldn't be too much hassle.
Having said that, I've been using msdeploy / publish profiles for about two years now and I've since moved to the following:
Create an msdeploy package using a Package.pubxml and define all your transforms using MSDeploy parameters (which are both more an less powerful than XDT)
Create a PublishProfile.pubxml file (so you can have the Visual Studio experience) but declare all your parameter values in PublishProfile.parameters.xml
Perform any "all environments except debug" transforms in a Web.Release.config to avoid overcomplicating your deploy parameters
Deploy the package on your build server by calling the generated .deploy.cmd (or msdeploy.exe directly)
This setup lets you continue to use Visual Studio to publish if you like but you can also move all the way down to the msdeploy commandline, since the .parameters.xml file is defined using the msdeploy parameter schema.
Web deploy parameters have plenty of "floating" documentation but no real "reference" home. Here's some useful links:
Web Deploy Parameterization
Reference for the Web Application Package
How to: Use Web Deploy Parameters in a Web Deployment Package
I have an ASP.NET MVC4 app and I'm using the hosted Team Foundation Service to automate builds and deploy to an Azure WebSite.
This works great except for deploying the database changes.
I'm using Fluent Migrator to specify the changes to the database and currently I have a custom implementation of IDatabaseInitializer so that when my Entity Framework context spins up, it does any migrations as necessary. Obviously this leaves the database migration until 'first run' of the application rather than the build and deploy.
What I'd like to be able to do is get the build to attempt the migration before it deploys to azure (and therefore fail the build if there's a problem with the migration).
Is this possible with the hosted build service? Can I add post-build steps as I can with a self hosted inhouse TFS?
Add the following to your .csproj file:
<UsingTask TaskName="FluentMigrator.MSBuild.Migrate" AssemblyFile="$(MSBuildProjectDirectory)\FluentMigrator.MSBuild.dll" />
<Target Name="Migrate">
<Message Text="Migrating database" />
<Migrate Database="sqlserver" Connection="YOUR CONNECTION STRING" Target="$(IntermediateOutputPath)YOUR DLL NAME.dll">
</Migrate>
</Target>
Also make sure the target is added after the Build target like so:
<Project ToolsVersion="4.0" DefaultTargets="Build;Migrate;Test" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
You may have noticed that I load the msbuild task from the project directory. I copied the FluentMigrator.MSBuild.dll AND the FluentMigrator.Runner.dll assemblies into my project folder. When I tried to load the assemblies from the packages folder I got an error saying the assemblies were not in the correct format...