I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
Related
I have always used the express versions of Visual Studio for my Asp.Net projects. In the past, I would use a basic FTP synchronizer to push updated files (*.vb) to our server, then the changes would just show up on the website instantly. Now, for some reason, when I make changes to our *.vb files, they are not being reflected on the server after I synchronize over ftp, unless I build the project first. In addition, for our .Net 4.0 project, VS 2015 14.0.23107 is adding the following directories, with tons of stuff inside of them:
/.vs
/My Project
/Obj
There are loads of files within these directories which I have no idea what they do, and for some reason our project has taken on a completely different behavior. Now when we try to synchronize over FTP, there are a ton more files, and it seems that changing the actual underlying source doesn't work. We have to synchronize all the other files in the above directories, then we can see the changes.
Is this a new way they are doing things, or is this because VS is now free and we are getting a better version where we have to "publish" not "synchronize?"
Is there a way to go back to the simple way of doing things, where we just have a plain directory with our source files and sync them over to the server? Should we not do it this way? If not, what method should we be using and what files should we be pushing to the server?
I'll just promote my comment to an answer. There are several aspects of this question:
Use publish, this feature is already for long available in Visual Studio and works well. There is plenty of ways to customize it and it supports a lot of technologies, including FTP. It's also more convenient, systematic and reliable way of deployment than manually copying files to your FTP. You can also share your publishing configuration among developers and store several of them. No loss here.
I don't quite get why would you like to copy the source (.vb) files to the server. What you would usually like to achieve is to get compiled DLL's + resources copied to your server, and source files 'secure' on developers machines. You can compile your sources on the server if you really need it, but then just plug it into a source control, use ms build etc. Anyway, build/publish actions are there to prepare the deployment files for you, manual copying is pure bad.
For the new folders:
Obj is everything but new, its created to store some resources, crap, more here: What is obj folder generated for?
.vs stores user specific settings, and you should ignore it as well as obj folder, more here:
Should I add the Visual Studio 2015 .vs folder to source control?
My Project is most likely your own folder, nothing related to VS.
To sum up, as long as you use asp 4, 4.5 nothing changes. Only the 5.0 intruduces a bit different rules for deployment. Most of the problems you get are easily solved using the right tools (Publish). It will know what files to ship (binaries + resources included in project) and what to ignore (source files, caches, crap). It's convenient, less error-prone and can do much more for you.
Definitely, use "Publish" option (right click on your web application at solution explorer, under Run/Build options), thus you can update your server site with those files created on Publish. As Mikus mentioned, you DON'T need vb files on your published site, you just need dll's and resources (images, js, css, resx, e.g.).
Regards, hope it helps.
Use the Publish Option which is provided by Visual Studio.
This will compile your project and you can then host this in your reliant manner.
I personally host on IIS and considering I have no data stored locally I can publish directly to the published path on the IIS Server.
The Publish tool is very simple and only takes a few minutes.
I have a website with huge number of pages, i keep pre-compiled version (with fixed naming) on production server.
Every time i make any change on my code i have to Publish the whole website just for a small change.
It takes about an hour to get the website published before i can deploy my changes to production server.
Is there a way to publish only a batch of pages so that the Publish process is faster?
Is there any other option to save the publishing time?
NOTE: By publishing I mean pre-compiling
Any suggestions are welcome.
If you're modifying only the html tags (nto the server side tags) or css, you can deploy only the part you changed.
If it's compiled code you got no choice.
I think you might have to ask your self why it's taking an hour to publish your web site ? Is your compilation time that much long ? .
One method to reduce the compile time, and size of a web-site project is to split your website into several smaller and more maintainable sites.
You can still deploy these separate publishes together in production.
References to pages from other projects work perfectly. All your pages within the same application on IIS will share the same session. So to an end user, this will still appear to be one website.
Since you reduce the work to be done while publishing any given module publishes will be faster. Divide your modules as per what you see as a suitable batch.
You must be aware of this, but I will say it just for completion. When you publish a website you get the option,Use fixed naming and single page assemblies. Select this to have a different dll for each page in your bin directory. You only need to upload the pages and corresponding dlls where you made changes. If upload time is a concern, this will take care of it.
Microsoft doesn't really have an idea of "pre-compiling" if you notice your pages have 3 components to them, the *.designer, *.aspx *.cs. The *.cs all needs to be compiled into a *.dll to be deployed to your website. Traditionally there are two types of executables, exe's and dll's. Asp.Net websites are compiled into a dll for all the code behinds that run on the server. Microsoft does not have a way to "half" compile a dll and then merge it with the other half you haven't changed.
If your website is taking that long, to compile & deploy. I would suggest you have more of an architecture problem then a code problem. Where I work our main website is 3,000,000+ lines of code, to accomplish everything the user needs to do and does. We don't take an hour to deploy. however what we have done is broken our business logic up into a number of dll's over 100 dll's and our website project in and of it self is just the aspx and the bare bones code behind to drive the flow through to our business logic. This allows us to alter x number dll's with our changes to support a new feature, We don't have to deploy all 100 dll's every time just the ones that have changed, that's the nature of dll's. if our business logic was 100% contained in our website project, then our compile, deployment would be significantly longer.
You want to consider refactoring your code into dll's. Another option if you're not married to the ASPX/ASP.NET solution is to consider an ASP/MVC.NET solution. I would consider refactoring your site. If it takes that long there's some serious issues, even if you could break Data access into a separate dll, then you wouldn't have to constantly compile & deploy the dll which handles your data access, every time you changed the website, only when you changed the Data access layer as well.
As previous posts mention, you cannot do this in an automatic fashion, but you could manually deploy your files if you want to reduce your publishing time.
When publishing a website, all code files for your site are compiled into a single .dll file in the website bin folder and all .aspx files are be deployed to their relevant paths.
To update the site manually, simply build the website on your local machine to create an updated .dll and overwrite the .dll in the bin folder on the production server. If the source/HTML has been modified on any of your actual pages/.aspx files then you will also need to copy them over.
Steps:
Build website locally
Overwrite production server .dll with locally built .dll
Copy any .aspx pages to production server where HTML/Source modified
Very simple.
Have all the HTML content stored in separate files to the code. A database would be an excellent idea. All one would have to do to change some text or swap an image would be to go into the database or file for that content and change a few tags. I recommend MySQL.
:)
I am working to setup a build server using Team City to build and deploy asp.net web applications to a staging site with transformed web.configs automatically. Everything is working except that the code that ends up on the website (the aspx files) have the HTML in them when you open them in notepad.
Before all of this I was using web deployment projects with websites, and the code was compiled. If you opened one after it was deployed, it said it was a marker file.
I have tried some tutorials on how this process should work, but the code always ends up in an editable state (the html).
My question is:
What do I need to do to get MSBUILD from the command line to ultimately have precompiled code on the webs server?
Any suggestions, links, pointers, or ideas would be very helpful to me.
You need to invoke the aspnet_compiler tool to do this. There are some limitations or complications depending on exactly what you need to do for things like strong-naming. The MSDN article here has pointers.
I used to have MSBuild project steps that did this, but we decided to drop precompiling because our clients want to integrate our product into their internal portals, and precompiling made things complicated for them.
Are you using MS Web Deploy? I use it regularly for automated deployments from my Team City Build server to dev, staging, QA, etc. And I'm transforming configurations as well.
If you want to check out this alternative you can follow the excellent guide by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
The majority of our internal apps are built on a Java EE stack using Ant, and deployed to Tomcat with a WAR file. We have a build box that creates a Production-targeted WAR, and the WAR is then delivered to the Test environment. A script is run to convert the deployed webapp to point to Test data environments.
After a few cycles of Test -> Bug Fix -> Build -> Redeploy to test, the WAR file is then deployed to Production, and is then live.
I've recently inherited some ASP.NET 4.0 webapps, and their Build/Deploy is quite different; the code is built in VS, and then the entire project directory is copied to each environment. It is then tweaked by hand, and is occasionally rebuilt with a VS instance on the server.
This is a bit scary, as there are plenty of opportunities for tweaks in one environment to be forgotten, and thus require that we're playing around with our apps after they're "live", outside the bounds of testing, version control, etc.
So, all of this being said:
Is there an equivalent to the Ant/WAR mechanism in a .NET world? What's the safest way to create an executable artifact from a .NET webapp and move it between environments with minimal modification? I know that "best pratices" is a taboo phrase, but I'd like to dip into some expert knowledge before I remake Ant in .NET. :-)
Three technologies you need to know about to automate web deployments:
MSBuild - This is Microsoft's equivalent of ANT. Project files are basically just a series of MSBuild tasks.
WebDeploy - This is essentially your WAR/Tomcat equivalent, except that it creates deploy packages, and is meant for IIS.
XML Transforms - You should never have to manually edit configuration by hand. Config transforms are essential if you have multiple environments you need to deploy to.
Put all these together with your favorite Build server (I use Jenkins), and you can totally automate your entire deployment process to any environment. Each of these individual topics is too broad to cover in depth here, but you should be able to get started with minimal knowledge of each.
To give you an example of how simple it can be, here is a sample command line build that will deploy a website to a 2003/IIS6 box.
MSBUILD "MyWebSite.csproj"
/p:Configuration=Dev
/p:OutputPath=bin
/t:Rebuild
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/P:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://MyDevServer
/p:DeployIisAppPath="Default Web Site/MyWebSite"
/p:username=deployUser
/p:password=deployPassword
Working on an intranet where we have about 20 different web apps - some .net, some classic asp.
Currently each .net app is its own solution. There are advantages to this - we can build & deploy just one app, without affecting other apps, and all the apps share a session - but we can't use master pages, and there are real challenges using localization resources, shared css and js, etc. Build & deployment is done completely manually, which is a real problem.
I'm trying to set up a structure that will allow us to take advantage of VS2008 features, but still have the ability to update one app without affecting the others while still using features like master pages and localization resources, and sharing session between apps (so we can't set up virtual directories for each app).
If I set up single solution that looks like:
/Root
- App_GlobalResources/
- shared
-- masterpages/
-- css/
- App1/
- App2/
...
- AppN/
..
- ClassicASP1/
then the problem is that the build just produces a single DLL (Root.dll) - this will simply not scale to 20+ apps, all of which have different development cycles.
Is it possible (using nant, or some other build tool) to build multiple DLLs? In this case, I'd like to end up with Root.dll (contains the global resources at least) and App1.dll and App2.dll.
Any other suggestions or references I should look at?
I'm not sure you can do what you want to do, sadly. VS tends to make one DLL per unique project (not solution), and it appears you have just one project, so hence, one DLL.
I'd suggest you keep one project (csproj) per application, but use NANT to build them all (ie, one at a time, together, in order), and package them all up for deployment. That way you can do a single point deployment, but still keep the apps seperate.
I'm surprised you can't use master pages in the sub-folders. You'd need to replicate them for each AppN folder, but again - NANT could be used to pull those in from a common place when you build your deployment package.
Writing a build and deployment script takes a while to get right, but I've found that once it's done, it pays for itself very quickly - even if the only payment is your sanity!
There is a solution to this problem. In short, it entails creating a Web Site Project (which can have the masterpage and whatnot) and several subdirectories, each containing a web project. In the main web project you exclude the subdirs from the project. You then add the project files to the solution. This (updated) link tells you all about it.
-Edoode
I would advise using MSBuild instead of Nant. It is more native to visual studio.