I am currently working on automating the build and deploy of an asp.net web application which is developed using vb.net in visual studio. Currently, developers are building the solution and projects using visual studio IDE. In the solution, they have deployment/setup projects (vdproj) for each environment (e.g.: app.setup.dev, app.setup.uat, app.setup.prof) which creates msi for the deployment and the web.config is embedded on it.
We are using github for scm, jenkinsfor build/CI and udeploy for deployment.
I am able to build the solution using msbuild cli thru jenkins. However, vdproj cannot be built using msbuild. Alternatively, I installed Visual Studio and MS VS Installer Projects Extensions in my build server, then build the vdproj using devenv. I am not sure if that is a correct way, maybe it is just a workaround.
What is the appropriate way to package the deployment artifacts (contents files, dlls, web.config) and deploy them? And How? If there’s another way to do it rather than creating MSI, it would be great as I don’t have to get a license for the Visual Studio in my build server.
I am currently working on automating the build and deploy of an
asp.net web application which is developed using vb.net in visual
studio.
Maybe you can try publish asp.net web-app by msbuild command-line.
1.As far as I know, we can build and deploy by Visual Studio, see this document.
2.And without VS, you can build and deploy(publish?) by msbuild command-line, there are many resources about this topic.
See:
How to deploy an ASP.NET MVC application on build using MSBuild in Visual Studio 2015?.
How to build and deploy a web deployment package using MSBuild
Using MSBuild.exe to “Publish” a ASP.NET MVC 4 project with the cmd line
In this way, you can get similar function by specifying the parameters and don't need to have VS installed in the server.
What is the appropriate way to package the deployment artifacts
(contents files, dlls, web.config) and deploy them?
Do you have to package them into .msi or .zip and then publish it. If not, simple msbuild command like: msbuild xxx.sln /p:WebPublishMethod=xxx /p:PublishProfile=xxx is enough.
Not certainly sure if it's what you want, hope it helps.
Related
We have for a while been building various web projects with AzureDevops and self hosted build agents.
Today I had to add a new build, consisting of a windows service written in .net core 3.1. This service has to be installed by our customers, so we have to provide it in a friendly installable way. As some of our developers were already used to handle MSI/*.vdproj projects, they added a vdproj into the *.sln to manage that. On a developper machine, this is not a problem even with VS2019: you just have to use the relevant VS studio extension...
But when it comes to building that in a CI/CD context, this becomes a real challenge. I quickly understood that we can't use MSBuild at all for that and found some alternative using directly Visual Studio (devenv)... Inspired by this thread (still opened), I came up with the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv" [...]\MySolution.sln /build "Release" /Project MyInstallationProject
This worked fine both on my developer machine and even on the build agent machine. But when I add it into a build pipeline as a command line task, it seems to hang, and after a while I get the following result for the job:
##[error]The job running on agent <MyAgent> ran longer than the maximum time of 60 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
What can I do to make it work?
What are the best practices for generating a self installable in a CI/CD context? (Is MSI still relevant? )
As a workaround, you can try to install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
Here are some tickets(ticket1, ticket2) with similar issue you can refer to.
How do I compile and run an ASP.NET MVC app using nothing other than the MSBuild command line? My Visual Studio is super slow and I just want to be able to run an app quickly for bugfixes and showcasing etc. Is this possible? What's the command line for it?
MSBuild is for building your application. If you want to run your app outside of Visual Studio, you need a web server for it. I'd recommend you to publish your app on local IIS. Just point your IIS website to your Web project folder. After that you will be able to access your application from the browser without running it from Visual Studio.
You can build your project from command line. Use msbuild.exe utility for it:
msbuild.exe projectname
You can find it in one of your .NET Framework folders (I recommend you to use the latest one):
C:\Windows\Microsoft.Net\Framework\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v2.0.50727\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v3.5\MSBuild.exe
C:\Windows\Microsoft.Net\Framework64\v4.0.30319\MSBuild.exe
When IIS is set up, you can build your app and see changes in your browser. Visual Studio is not necessary at this point.
Instead of IIS you can use IIS Express. Here is an article of how to run application on IIS Express from command line.
My team uses Visual Studio Team Services to manage our source code in a TFS repository. The solution contains multiple web apps. I am trying to configure Continuous Integration and Continuous Deployment for this solution such that each web application is deployed to the correct Azure web app after a successful build. I've configured the BuildDefinition to build $/MyProduct/MAIN/MySolution.sln. I've defined the following parameters to MSBuild based on some MSDN articles I found on this subject:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.stagingDirectory)"
The build steps include a Visual Studio Build step, a Visual Studio Test step (currently disabled to minimize complexity), an Index Sources and Publish Symbols step (which I don't think I really need), and finally, a Copy and Publish Build Artifacts step.
I am able to build this solution using this configuration. I can see the build results, the build log, build details, etc. When I look at the artifacts that are created, I see two artifacts: "drop" and "build.sourceLabel" If I explore the drop file using the Artifacts Explorer, I find all of my projects in this drop file, and for the web app projects, I can navigate into the webapp1\obj\QA\Package\PackageTemp\bin folder and see all the DLL's etc. for the web app.
What I don't see is one zip file per web app, which is what the Release feature of Visual Studio Team Services is expecting.
I would like to know how to modify my current configuration so that I can generate the correct artifacts from the Build step so that I can create the correct Release Wep App Deployment tasks to deploy each web app to the correct web app in my environment.
This is all being done with Visual Studio 2015 and Visual Studio Online (Team Services).
To test your situation I used Visual Studio 2015 and created 3 new web projects in the same solution and checked into VSTS. I then created a new build using the Azure Website deployment template. Many people miss that we have Build and Deployment templates on the Create New Build Definition dialog. The reason I use the Azure Website template is because I can never remember the msbuild arguments to pass in. You can simply delete the Azure Web App Deployment task if you are going to use RM.
One change I always make to the msbuild arguments is the PackageLocation. I always change mine to $(BuildConfiguration). That way I can build both Debug and Release at the same time should I desire.
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(BuildConfiguration)"
Finally I change my Copy and Publish Build Artifacts task to search for just “**\*.zip”. Leave the Copy Root empty and run your build.
When your build completes you will have one zip per project under the [ProjectName]/[Configuration]/projectName.zip when you explore your artifacts.
If you have further questions you can ping me on Twitter #DonovanBrown
I have an ASP.NET Web API project created on Windows using Visual Studio. How can I set this up for use with DNX/DNVM (on a Mac)?
Switching to Git solved the source control compatibility with TFS. But I wasn't able to find references to getting a project working across both these development environments.
I'm assuming as a first step the project will have to be migrated to ASP.NET 5/vNext but wondering other problems lurk around the corner with different project members using different environments.
I get an error when I run - git:(master):dnx . kestrel
As you mentioned yes you will have to migrate any namespace changes. I have a project that is developed across both. Also changing csproj files to xproj. Support is coming for some kind of interop between the different project types but its not here yet.
For build, publish, deploy from git without relying on VS publish capabilities or MSBuild you can follow my blog post here.
Basically you use DNU to publish and then kudu to deploy.
I'm about to upgrade to Visual Studio 2010, and I'm learning that there are now a few options for deploying web application projects. I've been using Web Deployment Projects in 2008, and my initial thought was to do the same in 2010.
Is there any advantage to using Publish or the Web Deployment Tool over Web Deployment Projects?
I need to automate the process so that the build and the deployment can be run from TeamCity. I'd prefer a method that would allow me to use the Visual Studio (sln) Runner but a custom MSBuild script would be OK too. See Web Application Deployment Workflow with SVN and TeamCity for more information on my current build/deployment workflow.
They both accomplish the same end goal, but they work very differently. In the end I used the new Web Deployment Tool. I chose it for the following reasons:
I can build my solution without installing any add-ins and with VS 2010 Express. MSDeploy is executed on my build server from an MSBuild script
MSDeploy seems to be the preferred method.
Web.config transformations are more flexible than WDP web.config section replacements. Only certain config sections could be replaced with WDP, but transformations are simply XML transformations that can apply to anything.