Follow up to this question:
Application Insights added ConnectedService.json file to my project, what does this do?
When I create a deployment package, via "Publish..." option, the package also include the following folder and files:
Service References\Application Insights\ConnectedService.json
I do not want to deploy something that is not required at runtime. Do I have to include the folder and file in my production server deployment?
No. Those files are only used by visual studio for its information, to know what services have been added and give you links back to them inside VS. None of that needs to be deployed. those files can all be set to do not copy/etc.
Related
I'm doing a web site deployment in azure with bit bucket source.
When I do the deployments I can see always its building the source,
Actually that is not required to me, because it is a Kentico 10 web site (.Net website project).
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You should stop using continuous integration process in bitbucket and hook your own process to do a xcopy (preferably delta) to target website folder.
Using the OOB tools it is not possible to deploy without a build. So you can do a few things:
FTP
Visual Studio publish
command line copy after a successful build locally.
Another setup could reduce the number of builds you have when deploying but will still build the solution, more branches in Bitbucket.
You could continue to use CI but make sure you hook your environments to proper branches so they only deploy when you perform a merge into that branch.
How do i avoid building while source deployment/ pull the latest from bitbuckt ?
You could check the deployment details under "DEPLOYMENT > Deployment options" as follows:
And you could leverage KUDU and check the auto-generated deploy.cmd file under D:\home\site\deployments\tools\deploy.cmd.
For your requirement, I would recommend you customize your deploy.cmd file, and put .deployment and deploy.cmd files into your Bitbucket repository. For a simple way, you could just download your current deployment script and modify the scripts under the Deployment section, you need to remove the script for building your solution and just leave the script for kudu sync, and you need to modify the value for the -f option from "%DEPLOYMENT_TEMP%" to "%DEPLOYMENT_SOURCE%" when invoking the %KUDU_SYNC_COMMAND%. Details you could follow Custom Deployment Script.
If you want to deploy the full content of your repo with no build or transformation at all, just set SCM_SCRIPT_GENERATOR_ARGS=--basic in the Azure App Settings. This will force the script generator to treat is as a 'basic' site, and won't do any build.
See wiki for more info.
Deploying a ASP.NET web app to Elastic Beanstalk. Trying to find the proper way to deploy the app from Visual Studio using the AWS extensions. I've read up on the AWS ebextensions config files but I've also seen something on SO that there's quirks with ebextension files and Windows deployments. What I want to do is deploy my web app which relies on many private .NET dlls that need to go in the web site's bin folder. Right now I reference them directly from the project itself and mark them as 'Content' and 'Copy If Newer' in VS. Wondering if the better alternative is to package up these bin files, upload them to S3 and use the ebextensions to get them installed as part of the deployment process for an EB app. I'm struggling with how to properly do the latter idea. Any ideas on best practices for this case?
You cannot. The dependencies required for any application should be included in deployment package.
I'd suggest you to adapt best practices and get rid of the DLL's included in your project folder. You can create packages for your dependencies and reference them from any other project. Take a look here. This way you can prevent duplicate dll's in deployment package.
I have an ASP.NET web site - aka, I don't need to build the project and deploy dlls along with the project, I just place the .aspx and .aspx.cs files on my web server and things are compiled automatically.
I would like to setup TeamCity as a continuous integration server for this project so that it will only deploy the files that were checked in rather than updating every file in the project when I leave a specifically formatted comment during checkin.
So far I was able to setup a build trigger that only fires if the comment is formatted correctly, but I can't find a way to tell TeamCity to only deploy the files that have been checked in rather than the entire project.
Can this be done? If so, can someone point me in the right direction?
I would use Microsoft's WebDeploy. It will automatically deploy only the files that have changed.
Troy Hunt's guide to setting up build and deployment in Team City along with WebDeploy is an excellent place to start:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
Also, if you prefer a more manual approach, you could use RoboCopy to do a sync:
http://itbloggertips.com/2013/05/robocopy-command-copy-only-new-changed-files-sync-both-the-drive/
I know you can copy a Website intact to the server and have it run normally (security and compilation time aside).
What about the projects that are in the solution? [whose dll's are copied to the bin when built]. Is there a way to copy the projects' code files to the server as well?
My goal is to be able to debug [by modifying code in the project if needed] directly on the server without having to install an IDE [or keep building on dev machine and copying over dlls]. I can debug/modify the website files, but not the projects.
EDIT: to clarify, not just debug, but be able to edit.
So long as you upload both the DLLs and the PDBs, you should be able to debug successfully without the raw projects on the server. It can be augmented if you have open the matching project / solutions locally. There really isn't a requirement to upload solution, project, or raw code files to the server to debug effectively, remotely. It should be noted that breakig while debugging will hang the app domain on the target application, and as such, should be done with caution in a multiuser environment.
You do not need the project files in order to debug files.
You should read about remote debugging.
Update:
What you want to do sounds very dangerous in a production environment. If you want to develop, develop locally.
Regardless - project and solution files are organizational tools in visual studio as well as build files for the MSBuild build tool. If you don't have either visual studio or MSBuild installed on the server, there is little point in having the project and solution files on it.
Why do you need to develop on a production machine?
When I build my ASP.NET web application I get a .dll file with the code for the website in it (which is great) but the website also needs all the .aspx files and friends, and these need to be placed in the correct directory structure. How can I get this all in one directory as the result of each build? Trying to pick the right files out of the source directory is a pain.
The end result should be xcopy deployable.
Update: I don't want to have to manually use the Publish command which I'm aware of. I want the full set of files required by the application to be the build output - this means I also get the full set of files in one place from running MSBuild.
One solution appears to be Web Deployment Projects (WDPs), an add-on for Visual Studio (and msbuild) available that builds a web project to a directory and can optionally merge assemblies and alter the web.config file. The output of building a WDP is all the files necessary to deploy the site in one directory.
More information about Web Deployment Projects:
Announcement on webdevtools MSDN blog for WDP 2008
ScottGu introduction to WDP 2005
The only disadvantage to this solution is the requirement on an add-on which must be available on the build machine. Still, it's good enough for now!
ASP.NET doesn't have real xcopy deployment for new sites. It depends on having a virtual directory/Application in IIS. However, once that virtual directory is created you can use xcopy for updates.
You can Publish Web site..If you want to automate your deployment, you need to use some script.
Have you tried using the aspnet_compiler.exe in your .net framework directory? I'm pretty sure you can create a "deploy ready" version of a web application or web site.
The _CopyWebApplication target on MSBuild will do exactly what you need. The catch is that only the main assembly will be copied to the bin folder and that's why a copy task is needed to also copy any other file on the bin folder.
I was trying to post the sample script as part of this post but wasn't able to.
Please take a look at this article on my blog that describes how to create a MSBuild script similar to the one you need.
Have you tried right clicking the website in Solution Explorer and clicking 'Publish Website'?
Build --> Publish
A dialog box will appear that will guide you through the process.
For the automated building you describe in the update, I would recommend you look into MSBuild and CruiseControl.NET
It depends on how complicated solution you need, you could just use a script and jenkins for example. You can use MSBUild with Jenkins for just deploying to an IIS. And if you got Jenkins other tools is pretty easy to connect into it later on. But if you just want to build, use a script that jenins execute every build that uses MSDeploy and it will work great.
This is how i do it, just to give you a feeling:
Sonarqube uses Gallio, Gendarme, FXcop, Stylecop, NDepths and PartCover to get your metrics and all this is pretty straight forward since SonarQube do this automatically without much configuration.
Here is Jenkins witch builds and get Sonar metrics and a another job for deploying automatically to IIS. I use a simple script one line that calls my MSBuild and wich URL, pass and user.
And Sonarqube, all metrics for my project. This is a simple MVC4 app, but it works great!:
If you want more information can i provide you with a good guide.
This whole setup uses MSBuild, too build and deploy the apps.