What is the best way to deploy the output of dnu publish to Azure website? I do not want build to trigger at the Azure side, because it takes forever and often breaks.
One trick i do is to exclude un needed folders such as bower or node packages or any other folders by adding it to the exclude configuration in project.json.
check out a reference for the project.json exclude list to follow: http://docs.asp.net/en/latest/dnx/projects.html#building
hope this helps.
Related
I wanted to publish my project in Azure Devops pipeline but I encountered several errors.
I tried to publish one of the .csproj file of my solution (.sln) from VisualStudio2017 it worked perfectly but when I try it with Azure Devops pipeline then it shows the below error. I've googled everywhere but not able to find the correct solution to solve my error.
My pipeline looks like this
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\Node.js Tools\Microsoft.NodejsTools.targets(201,5): Error : web.config not found in project, to create a project to deploy to Microsoft Azure you must create an Azure Node.js project. Process 'msbuild.exe' exited with code '1'
Tried adding the basic web.config file even that doesn't work.
Building and Publishing on Azure Devops Failed
To resolve this issue, you can try a quick way to solve it is by creating a Blank Azure Node.js Web Application and copy-paste the web.config into your project.
Check more details on section "Converting to an Azure project type" of page: https://github.com/Microsoft/nodejstools/wiki/Publish-to-Azure-Website-using-Web-Deploy:
The easiest way to get them is to create a new temporary Azure project
type, such as:
Blank Azure Node.js Web Application Basic Azure Node.js Express
Application Starter Azure Node.js Express Application Basic Azure
Node.js Express 4 Application And copy the missing web.config and bin
folder from the new project to your existing project.
Note that in web.config, the starter .js file (app.js, server.js or
something else) appears a few times. Make sure that it matches your
starter file, otherwise your application won't run properly when it's
deployed on Azure.
Hope this helps.
Try to delete delete and create a new solution or override the existing solution.
Then build it locally and then, check-in & build in azure CI pipeline.
It worked for me hope it works for you too.
Short Question
Is there a way to programmatically download all of the Nuget packages needed to build/publish a solution and output them into a single directory that can be moved to a local Nuget repository?
Some Background
Where I work, most development is done on an air-gapped network (no internet). On a recent project, I was able to develop on our internet-enabled network. This happens to be the first application developed on the internet-enabled network and the first ASP.NET Core app we've ever developed. The solution builds, runs, and publishes just fine on the internet-facing network. I am now trying to move the solution to the air-gapped network, but I am having issues getting all of the dependencies moved over.
At first, the solution wouldn't build because of missing ASP.NET Core nuget packages; so I copied ALL of the nuget packages from the local cache on the machine that I used to develop the application to the local Nuget repository on the air gapped network. Now the application builds, but I can't seem to publish the web project (ASP.NET Core). I'm getting 25+ errors along the lines of:
Unable to find package runtime.any.System.Diagnositics.Tools. No packages exist with this id in source(s)...
Unable to find Nicrosoft.NETCore.App with version (>= 2.1.6)...
Unable to find...
I'm also getting a runtime error "This page cannot be displayed" when I try to run from visual studio (using IIS Express), but I'm not sure if that's a related issue. The unit/integration tests run fine.
I could try manually downloading each nuget package from Nuget.org and moving them over to the air gapped network, but it takes hours to get things moved from one network to another. Is there anyway I can automate the retrieval of all nuget packages required to build/publish a solution so that I can make a single transfer from one network to the other instead moving what I have and waiting to see what breaks? Preferably I'd like a exe or a PowerShell script that could look at a sln file and drop all the necessary nuget packages into a specified directory.
On your internet enabled dev env, you can browse to the root directory of your project and use:
dotnet restore --packages .\package\
This will use the directory called 'packages' as the local cache for the solution and all nuget files will be copied to it.
You can then include the same switch in your build, to ensure that the local cache is used.
dotnet build --packages .\package\
I answered two very similar questions a few weeks ago. Have a look at these answers to see if they help
Command to download a Nuget package with all dependencies to a folder
Is it possible to create a cache of nuget packages for computers without internet?
Via VSTS I am trying to automate the following process which is currently performed manually:
Within VS 2017 perform a publish to file system.
Set settings in web.config.
Repeat 1 & 2, for each environment, e.g. Test, UAT, Production, etc.
Copy those files to an FTP server.
Logon to secure infrastructure, download files from FTP, and copy into place on IIS target servers.
The secure infrastructure is locked down, and has limited internet access. The FTP is used as a way to move files into that infrastructure.
Within this question I specifically want to address elements; 1, 2, and 3.
The struggle I am having is that VSTS seems setup to deploy web apps into Azure Web Sites or publicly accessible IIS. Whilst IIS is my eventual target, initially I was hoping to achieve a file system deployment - similar to what VS 2017 provides.
I have tried using MSBuild to create a package, using; /p:WebPublishMethod=Package /p:PackageAsSingleFile=true.
Then MSDeploy to extract the package into a folder msdeploy.exe -verb:sync -source:package="Package.zip" -dest:contentPath="content".
However that results in the following error Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
It looks like I can use MSBuild and /p:DeployOnBuild=true /p:PublishProfile=VSTS to deploy to a folder at build time, but that seems a little awkward within the structure of VSTS. E.g. I have to repeatedly build the solution for each environment.
After I have the solution deployed into a folder, I intend to use VSTS to push to FTP.
Is there a better way to do this? For example; VSTS Azure deploy provides the ability to easily set connection sting parameters.
You can achieve what you want to do with the FTP Upload build/release task.
1 - You don't have to publish to the file system.
Just create a new build definition based on asp.net application template:
This will add the tasks you need to build and package and as a final step to publish the artifacts to a drop location.
After you published it to a drop location you can either continue on build by adding the ftp task or you could add the ftp task to a release pipeline. This is up to you.
The ftp upload task then needs to be added after the publish artifacts task, like:
For 2 and 3 it is best that you use a release pipeline, where you can add several environments and tasks to it. That you can add your ftp task and get it from artifact (your build) that you will add to the release. The web.config settings can also be changed using release tasks.
I have create a sample ASP.NET 5 application (pretty much the example one from New Solution), and pushed it to GIT hosted on Visual Studio Team Services (former Visual Studio Online). I want to set up continuous integration to Azure Web App (former Azure Web Site). I have tried to set it up from Azure portal itself, it did create a new build definition, but it fails to build ASP.NET 5. I have found a guide how to do this, but it never really worked for me, I get errors like this e.g.
Error parsing solution file at C:\a\1\s\Frontend\src\Frontend\Frontend.xproj: Exception has been thrown by the target of an invocation.
Predefined type 'System.Void' is not defined or imported
Another problem is that it seems it really takes a lot of time to install dnvm, get packages, etc. So all in all it's a pain to make it work.
So are there real alternatives for that or more importantly is Microsoft is planning to implement something like a Build ASP.NET 5, Deploy ASP.NET to Azure and such to make it easy as I suppose it's easy with the current ASP.NET 4 apps. I really hope that it will be an option soon since it's quite impossible to work with current build system.
For "System.Void" issue, please check the runtime version in "global.json" file and make sure it is consistent with the dependencies in "project.json" file.
For dnvm install issue, since AspNet5 runtime environment isn't installed on VSTS Hosted Build Agent for now and the different users may use different runtime versions, it requires the user to add a "PreBuild" PowerShell step to read the runtime version in "global.json" file and then install it. If you can make sure that you will always only use one version (For example: 1.0.0-rc1-update1), you can deploy your own build agent and install "1.0.0-rc1-update1" on it, then you can skip the dnvm installation during the build process.
Take a look on http://riffer.eu/wordpress/?p=112. There I have a solution vor asp.net core RC_1.
Amazingly you need only two powershell scripts - there is no compiling / visual studio necessary.
Here's what I want to do:
Build an existing .csproj that targets "Package"
Publish the package with MSDeploy to an IIS 6 server
This is for a TeamCity build and release that I'm trying to configure in a single step. I could create a custom build file but I'm trying to tackle this without adding any additional configurations to the app.
There are a lot of examples around of MSBuild parameters which can do this publishing via WMSVC - here's a great one - but that's not going to play ball with IIS 6. Are there equivalent params which can be used when there is a dependency on MsDepSvc? Is this even possible or am I left with either a custom build script or a package build followed by a publish build?
You can modify an existing .csproj file to add any additional target needed (it's just an MSBuild file) and publishing to an IIS6 server can be done via different MSDeploy providers (webServer60, metaKey, or contentPath via a share).
While this would be possible to do by adding a Target in the MSBuild of your project, I'd recommend that you split these two activities out into two separate targets. By splitting them into two separate targets you can still call them together msbuild /t:Package;Deploy but you can also call them independently.
This would allow you to create a deployment package and have TeamCity include it as an artifact of the build. You could then download this package from TeamCity and deploy it to any server independently, even if you deployed it automatically. If TeamCity also creates your release builds, you know have your production deployment