The company I currently work for has a solution with 3 projects.
_Common... which was originally a Web project, but then changed to a Class Library.
Website1... Which is a website
Website2... Completely different website.
In Azure, we have a Deployment configuration so whenever our BitBucket Repo gets a checkin, it should build and deploy the solution.
Unfortunately, it seems like _Common is getting built as the target project. Which is breaking Azure.
ALSO Unfortunately, we have Two DIFFERENT Products (Website1 and Website2) which are in Two Different Azure Apps. They are both looking at the same BitBucket Repo, and both building whenever a checkin happens... but both are building _Common.
Can I have our "Website1" Azure App build the solution with Website1 as the startup project, and have our "Website2" Azure App build the solution with "Website2" As the startup project?
This obviously won't work to set the default project in Github, since we still need two different builds with two different startup projects.
You certanly can!
Go to your "Website1" Web App and go to Settings > Application Settings.
If you are using .Net Framework 4.5 or lower
Add a setting called Project, which value points to the CSPROJ file you want to build, using the full path from the repository root folder.
If you are using ASP.NET Core 1.0 / ASP.NET 5
Add a setting called Project, which value points to the folder that contains the project.json file of the project you want to deploy, do not include the filename in the path.
Related
We have a site design that makes use of modules that are developed separately from the master site. Thru reflection, we pick up the modules when the main app starts.
This works fine in local development and on a normal web server. But in the Azure environment when we try to use FTP to deploy the modules to our Azure-hosted site we are unable to because the main Azure deployment is read-only (because it is running from a package).
Is it possible to not have the main site running from a package? Is it acceptable to run it that way?
Is there another way to deploy Dlls to the Azure-hosted site without having them be part of the main site's build and deploy? Ultimately we are trying to avoid rebuilding the main site every time we want to add a module.
our Azure-hosted site we are unable to because the main Azure
deployment is read-only (because it is running from a package).
You could set WEBSITE_RUN_FROM_PACKAGE=0in your app setting to make not read only. WEBSITE_RUN_FROM_PACKAGE=1 is read only.
Is it possible to not have the main site running from a package? Is it
acceptable to run it that way?
You could consider switch your deployment methods to Zip Deploy to make your Azure-hosted site not read only.
Refer to this doc.
What can help in this situation is to build and publish the modules using Azure Artifacts.
There are several approaches please check the best practices page over here:
https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/best-practices?view=azure-devops
Depending on your approach the build, the release but also local development can use these published modules.
Example
You can for example use a private nuget feed:
Publish the modules from your modules pipeline:
https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/nuget?toc=%2Fazure%2Fdevops%2Fartifacts%2Ftoc.json&view=azure-devops&tabs=yaml
Consume these from visual studio:
https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/consume?view=azure-devops&tabs=windows
And consume them from the website pipeline, this can be a build but also a release if you want to side load them:
https://learn.microsoft.com/en-us/azure/devops/pipelines/packages/nuget-restore?source=recommendations&view=azure-devops
To keep a record of what modules are used in the website, I advise to build or release the website if the modules are changed.
Im trying to test different things on Azure, and i have tried to setup a static webapp.
The github repo consists of nothing really.
These files are pretty much empty. Whenever i push something to the repo, the build triggers, but fails with the error Oryx built the app folder but was unable to determine the location of the app artifacts. Please specify the app artifact location through the Github workflow file.
Im uncertain of what it means with artifacts. This tiny webapp doesnt have any real build or anything
In the azure-static-web-apps-xxxxxx-xxxx-xxxxxxx.yml file the app_artifact_location is " "
Not really sure which artifacts its looking for, or what they are really.
You may want to investigate this Quickstart: Building your first static web app.
To add to this app_artifact_location is the location of the build output directory relative to the app_location. For example, if your application source code is located at /app, and the build script outputs files to the /app/build folder, then set build as the app_artifact_location value.
In step Build and Deploy builds and deploys to your Azure Static Web Apps instance. Under the with section, you can customize these values for your deployment.
Reference: https://learn.microsoft.com/en-gb/azure/static-web-apps/github-actions-workflow
Based on https://learn.microsoft.com/en-us/azure/static-web-apps/overview
Python-based frontends are not supported. Clients are served statically and are browser-based apps. The build system (0ryx) likely unable to determine the framework and is generating the error message you are seeing.
The default web page that is expected is index.html. It looks like you may have misspelled it = index.hmtl
I am trying to create automated build to publish a folder with files onto Azure web-site. And I cannot accomplish this.
I am NOT publishing a solution (.sln), but rather a folder with files. I am using VS2013 and Visual Studio Online.
I have experience with TFS web publishing, so I published solutions many times.
So, what I did so far:
Created an MSBuild build.xml file that just copies files from the folder to the output.
Created a build definition based on AzureContinuousDeployment.11.xaml
Specified build.xml in my build definition, Process tab, in "Solution to build" parameter:
If I build my project, it is correctly built, files are copied to the output, etc (I can verify it by opening drop location, all files are there).
Then, I:
Created a web-site in Azure, linked it to my TFS subscription.
Downloaded a publish profile (.PublishSettings from a web-site).
Created a Web publish profile (.pubxml) in Visual Studio based on .PublishSettings file).
Specified Web Deploy Publish Profile and Deployment Settings Name:
But now I am getting an error during build:
Exception Message: Please specify a Visual Studio Solution (.sln) to build. (type BuildFromSolutionException)
So it asks me for a Visual Studio solution, but earlier it worked perfectly with MSBuild file (after step 3).
I tried to rename my .xml to .sln (probably it is not what I should have done), and build now says "There was no Windows Azure project (.ccproj) detected in the solution. Continuous delivery to an Azure Cloud Service requires an Azure project. (type CCProjNotFoundException)"
If I don't specify "Deployment Settings Name", build completes without errors, but again no publishing to Azure.
So, the question is, how to publish a custom MSBuild build, without a solution, onto Azure? Is TFS continuous Azure publishing for Solutions only? I expect it to be agile, like I published folders from Local Git to Web-site without any hassle.
What should I do?
There are a few confused ideas in your question. Fits, there is no relationship between and automated build and Git. You are using Team Foundation Build to run the workflow of deployment. It is the workflow that is not working for you. In effect the build and deployment script. In fact the script you are using works with both Git and TFVC so that is not the issue.
That specific script is designed specifically for building an azure project that is then continuously delivers to Azure and you likley can't use it as you are. You can however create another script and use that. I would suggest you try instead to use the Default build script and use a powershell script within the build to collect the files and then push them to Azure.
If you want to go a little more advanced you could create a copy of the default and make one that does not require MSBuild at all.
I have created a new release build in TFS 2013 and I want to configure it to perform a web deploy. I am not sure how to specify which project to deploy. Ideally I want to web deploy 2 web projects to IIS on the server (both projects will have a corresponding website in IIS), but if it not possible I can live with having 2 separate builds. I have added the following setings to MSBuild Arguments (in Advanced section of the process) in build definition:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:Configuration=Release
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath="<IISSIteName>"
/p:MsDeployServiceUrl=https://<my server IP>/MsDeploy.axd
/p:AllowUntrustedCertificate=True
/p:username=Administrator
/p:password=xxxxx
I can see it is conneting fine, but it doesn't publish anything. I also tried to specify my web project in Items to build section, but that didn't help. What am I missing? Must be some setting.
If I have understood correctly, you have 2 web projects in the solution and you want to create build definition to deploy them as two different web sites on IIS server.
There could be better ways of handling this but what I have done in my project is to have two separate build definitions for 2 web projects.
For each build definition, specify the csporj file of the project to build under “items to build” section of the process tab.
Even after doing this TFS may not publish the web site at desired location. It may show success but files won’t be copied to the destination location.
In this case, check the log messages of the build activity. If you find a warning similar to this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (484, 9): warning: The OutputPath property is not set for project ProjectName.csproj'.
Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='Any CPU'
Then it may be related to build configuration. If you are using “Any CPU” as build configuration then change it to “AnyCPU” (remove space).
Refer following link for the detailed explanation:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/0bb277ec-a08c-4795-88f0-3207654e2560/the-outputpath-property-is-not-set-for-project-xxxxxbtproj-please-check-to-make-sure-that-you?forum=tfsbuild
Amey
I have a Visual Studio 2012 solution containing a Windows service project and a web application project.
I want Team City (version 8.0.3) to create two zip files (one for the service and one for the web app) that I will deploy manually.
Should I create a build step to build the entire solution, followed by a build step to publish the Windows service and a build step to publish the web site (via publish profiles). Then use Artifact paths in General Settings to zip up these two published folders?
Or should I have just one build step to build the solution and then use the Artifact paths to create the two zip files?
Or is there a better way than either of the above?
You have to ask yourself if these two projects are linked and in which manner they should be built together.
My feeling is : if your projects are in the same solution, they are linked in some ways and have to be built together.
Then, you should build your solution (sln) and not projects (*proj).
Application organization
Generally, your build server should not redefine -too much- the way your applications are organized. You should always use your plateform application descriptor to build your applications.
In case of .NET and Visual Studio, the application descriptor is your solution (sln). It defines the needs and how your application have to be built.
If your project have to be built separately, they should be in differents solution unless you prefer to create specific solution configuration (in addition to Release & Debug).
Anyway, the solution is still the build entry point.
TeamCity
Speaking about TeamCity, different and standalone applications should be in separate build configurations.
The pure build (code compilation) should be in one build step and you should not use too much code compilation runners in one build configuration.
Your build configurations should reflect your applications farm logic.
If you need to link them in some ways which are related to packaging for example, you can link your build configurations through snapshot or artifact dependency.