I am looking to deploy an ASP.NET MVC application using the Web Deployment Tool along the lines of this post. The way I've gotten that to work is by getting everything first working on localhost. But there's one catch. The way I've gotten things to run on local IIS is via the Visual Studio web tab, which requires setting up a Virtual Directory. The catch with that is that I'll ultimately want to deploy the application to the root of my website. I don't want to get involved with change path references like /Content. Any suggestions? Thanks!
I answered my own question. Rather than running on localhost in the way I described, I simply needed to Publish to there. noob mistake.
Related
I changed from running Use Visual Studio Development Server to Local IIS Web Server becasue I read it would create the virtual directories properly - it did not - once I navigate out of the account area I get
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Requested URL
https://localhost:443/xxx/Index
Physical Path
C:\inetpub\wwwroot\xxx\Index
I have been googling and trying to get it to work, but can not and can no longer debug - Now I am trying to change it back and it keeps starting in Local IIS Web. I have HOSED myself and don't know where to go from here.
Thank you
In terms of getting back to using the VS web server you should just need to:
Right click on the web project in VS
Selection properties
Go to the web tab
Select "use visual studio web server" radio button
For the sake of not leaving questions unanswered, I tried all of the suggestions above, and many more, and got nowhere. I was in an early phase at the time, and I had to move on, so I ended up creating a new solution, and porting things over. Not the best idea, but I had to go forward, and I had taken enough time. It is still living on my machine, and I plan to go back and figure it out at some point. Hopefully, I'll have more understanding and will be able to post what I did wrong so someone else can save some time. Thanks all for attempting.
I'm using Publish/Web Deploy to deploy an asp.net aplication from Visual studio 2010. It works perfect, but there is a problem. If the new release is not working as expected, the old version is already replaced by the new one and there is no easy way to roll back to the working version. How is this best solved? I wish it was possible to keep the old version on the server so I could just switch back if needed.
With WebDeploy there is no built in rollback feature, so once you've deployed that's it.
There's a number of hand rolled strategies you could put in place, for example:
Limited Access e.g. Shared Hosting:
Where you don't have full access to the machine -
Backup the live site beforehand by downloading it.
Keep copies of what you deployed so you can push the previous version should something break
Full Access:
Maintain two sets of folders for the application and map your site to one or other of these folders. When you come to deploy switch the IIS site's physical path to the other folder then deploy. If the site fails then just knock the site back to the original folder. Each successful deploy would alternate between these two folders.
For stuff like user uploaded content you'd need to map virtual directories to a place on the file system that's always the same place because you don't want to be copying these around each time.
You're not the only one who has encountered these issues. Have a look at this article by Rob Conery and his observations about the state of affairs regarding ASP.NET deployment.
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Using some form of Source Control would be another alternative. We use subversion, so if the publish goes bad, we can just update back to the last-good revision, and publish that. Even if you're the only developer, using source control can be very useful.
I am using Visual Studio 2010 and IIS 7.0 .Currently when I want to deploy an website to my web server I follow these steps -
1.Right-click on website and say publish..to get the entire site copied to a local folder.
2.Next using filezilla just ftp the copied files to the web server.
The problem is I have to deploy entire website all the time since I can't keep a track of the changes. Although I do find my way easier and without problems. I dont want to a whole lot of configuration and deployment packages unless it is really worth it and also relatively easy to do. Is there a better way I should do the deployment ? Any suggestions are welcome !
You could use the Web Deployment tool. It needs to be installed on the webserver too and can even take care of publishing a sql server database.
http://www.iis.net/download/WebDeploy
Do NOT use the Web Platform installer to install this package.
You can just right click on website and Publish Web Site; the Publish Website Wizard opens. You can click the ... button to browse on the Target Location textbox and choose FTP over in the left hand side, then put in your FTP credentials.
You can tick 'Allow this precompiled site to be updateable' so if you need to make minor changes (such as scripts, css, or html) but I don't know how reliable that is.
Good luck!
Scott Gu just published an article about the Deploy Features in VS today:
http://weblogs.asp.net/scottgu/archive/2010/07/29/vs-2010-web-deployment.aspx
Personally I use Dispatch for ASP.NET. Works well for me. It only uploads the files that have changed and can check for files that are missing locally or on the server.
http://dispatchasp.net/
If you are using the Publish Wizard then you have no choice but to deploy the whole site. There is no way for the wizard to look at the files on the server and know definitively if the file has changed or not (it could look at file size or something, but that's not 100% guarantee of no change and FTP doesn't offer an easy way to do a checksum algorithm).
Other then that, do it the way you would do it on any other language/tool. Just manually FTP the files you've changed. Of course, this means you have know which files are side-affected by your changes. And if you're not confident as to what files you've side affected.... publish wizard is your friend :)
we've recently stumbled across the excellent Dispatch for ASP FTP deployment plug in. It looks great apart from one thing: It doesn't work with Visual Studio 2010, at least for us, anyway. (It's supposed to work fine.)
(Yes, we've tried everything: We've managed to get Dispatch working for another FTP site, but not the main one we regularly deploy to. We have managed to connect to our main site through FileZilla FTP, so the site itself is configured correctly. All settings have been triple checked, but the software still throws up weird errors (always to do with its internal libraries).)
So does anyone know of any other comparable FTP-based, deployment plug-in for Visual Studio?
Here's what Dispatch does (and so any suggested replacement must do):
Monitor any altered files
in the project. When a file is
changed, it's added to a list of
files to be deployed.
To deploy these
files to the live site, all we need
to do is click "Upload" and the plugin will
connect via FTP to our live site and
upload the selected files.
We can filter out
any filenames we don't want to be
monitored/uploaded (e.g. .cs or
web.config or /Images/, etc.)
I think that's all the features that we need. Thanks for any suggestions!
Note: If you're wondering why we need such a service, it's because we deploy many site changes over the course of a single day. Publishing the entire project to a folder, zipping it up, then FTPing that zip file, only to have to unzip it, and then install the entire project into the live wwwroot takes far too long. With Dispatch you're able to upload individual files in a single click.
After much back and forth between me and the creator of Dispatch, we managed to narrow down the problem to the library he was using (Rebex FTP). I posted a question about the issue on the Rebex forums, and it was revealed that their software might have a bug with IIS7.5. They suggested a quick hack/fix, which I tested and discovered worked.
Mr. Dispatch then quickly implemented this hack/fix into his software, and lo! I had a fully working copy of Dispatch... So no need for a replacement any more!
(And from what I've seen, there isn't even any other plug-ins offering this functionality, so it's just as well.)
Just an update - Dispatch does not work with VS 2013 so if you have VS 2012 with Dispatch installed, Keep it. Also the website is gone so it looks like all development has ceased. I have been using Dispatch since VS2005 and it has been great for just sending single files up when I need to. Too bad it is gone.
I built a very simple one for myself - you right click the file in Solution Explorer and it then uploads that file based on a settings file you create.
It's super crude but it works and the source is there to make it better if you like -
https://github.com/garazy/vs-2017-ftp-upload
Big enhancements have been added to VS2008, VS2010, VS2012. Below is the article. I found that Microsoft did all the above while I was searching. Since this came up high in what I was searching, thought should share this knowledge.
Deploy a Web Application Project Using One-Click Publish Without Web Deploy
I created an ASP.NET MVC 2 application in Visual Studio 2008. I set the release build to go through the ASP.NET compiler to precompile all the views, minify Javascript and CSS, clean up the web.config, etc. Since the production deployment is going to an IIS6 server, I set up my pseudo-production deployment on my Windows 7 machine to have the application pool run in classic mode targeting the 2.0 runtime. I set up the extensionless handler in the web.config that's necessary and everything worked great.
The problem came when I upgraded the solution to Visual Studio 2010. I'm still targeting the 3.5 framework, but now I'm using MSBuild 4.0 since that's what Visual Studio 2010 uses. Everything still compiles correctly because it runs fine under Cassini, but when I deploy it to the same location (same application pool, identity, etc) it now behaves differently. I still have the extensionless handler in the web.config, but now when I navigate to the root of the application it does directory browsing, and any routes that it had previously handled now come back as 404 errors being handled by the StaticFile handler in IIS. I'm at a loss for what changed and is causing the break.
I have looked at this question, but I have already verified that all the prerequisite components are installed.
Did you try debugging your routes using Phil Haack route debugger on the server?
Edit:
On IIS 7.5 you dont need any special extensionless handler, this is handled automatically, you don't need to change anything. It is only necessary on IIS 6 as far as I know.
Could that be the problem? what if you remove that special handler? maybe this is what is stopping it to kick in the route engine.
Edit:
I double checked, and as I thought, starting on IIS7, the default mode of a AppDomain is Integrated Mode. This means that the Asp.net stack kicks in at every request, while in classic mode, asp.net was called only when an specific extensions where called (aspx ashx axd are mapped by default to the aspnet_isapi filter).
UrlRoutingModule is kicking in at every request without requiring anything from you because it is an HttpModule and not a Handler. (it just needs to be registered in the config file of your application, no need to map it to an extension, but that's by default in an MVC app. You can open you Web.Config file and verify that you have under a node
<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>
Are you sure you deploy the MVC assemblies to the server?
Check that System.Web.Mvc, System.Web.Routing and System.Web.Abstraction references have the Copy Local property set to true to be sure you use the same assemblies locally and on your production server...
If all that is correct, I don't know how to help you more... I hope this will help you, or at least put you on the right tracks.
EDIT:
Oww... just read your last comment... sorry I missed that element about classic mode. Your title mentions IIS7.5 and I assumed too much things. that's why I got confused.
Honnestly now, I had to look in the book of Steven Sanderson. He has a checklist for troubleshooting IIS6 deployment.
I know you're saying it's only when using MSBuild 4 that it fails, but it might still be usefull
Check that Default.aspx is set as default content page. That could be the source of 404.
Then to have extensionless urls, last time I deployed to IIS6 I used a simple wildcard map and I never had a problem...
If you're still in trouble sorry that I could'nt help... not that I didnt try :) good luck
I experienced this problem today, in a similar scenario.
The problem on my case was due the fact that asp 32 bits was registered instead of the 64 bits, causing the problem with the routing.
It was solved by typing the following in the command prompt
CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i
Couple ideas to try
Have you run any kind of comparison
between the output of the VS2008 and
VS2010 projects? Just verifying that the
solution upgrade didn't change
anything.
Do you have the web.config
targetFramework attribute set on the
compilation element?
Are you certain you're not running
into something like running a x86 application
in a x64 app pool?
I'm guessing you're fine on those, but since Cassini has no problems with the application, I still lean toward web.config issues. Do you have your modules/handlers properly registered in the element? Since you're running Classic Mode, you'll need both the "old" and the "new" (reference 1, reference 2).
I've already posted this solution in another thread, but I'll repeat myself.
Use classic pipeline mode of AppPool:
Also dot't forget to install HTTP Redirection module in Turn Windows features on or off.