When I use Build->Publish Web Site in Visual Studio 2008, most of the time it compiles the site, and then simply asks me "All files in the target folder will be deleted. Continue?" (or something to that effect). On occasion, however, when publishing a project in Visual Studio, I would get a dialog box that would give me the choice of replacing the folder's contents completely, or simply replacing changed files with newer version.
I much prefer to publish without completely obliterating the folder, because the deployed application creates user files and cache files as it's been used that I don't want to take extra steps to preserve. However, I'm not sure why Visual Studio doesn't always give me this option. Is this a setting somewhere I can change? Is it tied to the version of .NET I'm using?
Any insight is appreciated!
Edit - Followup on 2009-01-20
I still haven't figured this out, but here's some more information.
Here's what the publish function looks like for one ASP.NET project on my Win XP desktop:
And here's what it looks like for a different project on my Vista laptop:
Notice the radio buttons in the second screenshot that allow me to choose to either delete the contents of the folder prior to publishing, or merely to overwrite matching files. I'd like to have these options for every project.
Both computers are running Visual Studio 2008 Professional (version 9.0.30729.1 SP, according to Help->About). The exact same version. And I doubt the OS difference is causing this functionality change. It's got to be a setting somewhere, right? Does anyone know?
John is right, the only difference is one of your projects is a Web Site Project and the other is a Web Application project. You will not see the "convert to web application" option unless you are in a Web Application project. I know... it is very misleading. The reason behind this stems from the the way you convert to a web application project. If you plan on converting it(which can be a real pain in arse, depending on how it is set up) then you need to be aware of a few differences:
In a Web Application project everything is pre-compiled all the codebehind pages will be compiled into a .dll ---- In a Web Site Project nothing in the project is pre-compiled, the compiler will compile everything to ensure it is valid but none of the compiled pages are uploaded. When a user first attempts to access the site each page is compiled into its own dll. This means in a Web Site Project you are able to upload a single codebehind file.
Namespaces - In a Web Application project namespaces are created by default in a Web Site Project they are not. So you may have to spend some time adding them if you plan on converting them.
Project files - you will notice that A Website Project does not have a "cproj" file a Web Application project does.
I have converted a few of these project I find they go fairly smooth as long as there is not a lot of code in the "app_code" folder. You can give it a try and see how easy it is, if it looks like it is going to be a pain, I would suggest FileZilla just FTP it and save yourself some headache.
Good Luck
That dialog is different for Web site projects and Web application projects. In my MVC projects (Web application projects), I see the additional options. In my regular ol' web site projects, I see the first dialog posted.
Not sure if this option will be suitable for you but you could use the copy website function from the solution explorer. Click on the "Copy Website" icon at the top of the solution explorer.
I think the real answer to your question is that you should put your user files and cache files somewhere else.
When publishing a web site Visual Studio is designed to make sure that the target folder contains your web site files, and absolutely nothing else.
Apparently this feature is coming in VS2010 - that's what Vishal Joshi announced at TechEd EMEA in session "PDC307: Microsoft Visual Studio 10: Web Development Futures"
The site has been updated from the site in the updated layer.
Related
I am working on an asp.net mvc-5 web application , and i am using Visual Studio 2013 , to publish my web application to an online hosting using web deploy.
now i published my web application correctly. and i check it online and every thing is working well.. then today i modify a view named "Contact.cshtml" and a file named "style.css", and then I try to publish again. i was expecting that only the two files will be shown in the preview window since they differ from the publish files. but i was surprised that my project.dll is being listed although i did not chnage it (i did not modify any cs file) and the modified date for this .dll is that same modified date which is online..so can anyone adivce on this ?
here is how the preview window inside VS 2013 looks like:-
So can anyone advice why my project.dll file is listed although i did not modify it since i did my last web deployment ?
Either you ran the project before publishing and/or your are building your views in the solution.
It may be that your style.css and Contact.cshtml files have the wrong Build Action. The proper build action for these files should be "Do not copy", which seems counter-intuitive since the Web Deploy will copy it anyway. You can change the Build Action by selecting each file in the solution explorer and setting the appropriate value.
So I have an Asp.Net website that i'm responsible for. I'm having a build issue, that as far as I can tell, may be either MacAfee or some other random cause.
But thinking back, I want to say the problem started when I added a "Test.aspx" form to the site, did some testing, then removed the Test.aspx form from the site.
I'm using TFS 2010 as my source control as well. Which I don't know if it applies or not.
My question is, is there some hidden location where all files to be included in publishing a website is maintained?
Is there a Project file for a Web Site app and if so where is it?
I've built the site using MSBUILD and notice some metaprj project file in the output but I can't seem to find any such file.
Web Site apps aren't meant to be built into a dll file. There is a conversion wizard to make it a web project but it doesn't always work well. My advice would be to continue to work with it as a Web Site app. The code files are compiled at at runtime on first use. You can run from Visual Studio or setup a site in IIS. Nothing is hidden in a Web Site app and there is no project file. So, you shouldn't have a build issue because you shouldn't be building. Try to run the app as is and if you get an error let us know what the specific message is.
So I'm using visual studio 2010 to build a website that was formerly running on PHP, so I'm pretty new to the environment.
In starting the project I built a website project, not a web application project. I know that will probably generate a lot of "never use a website project, use a web application project instead" comments, but bear with me.
I'm attempting to provide our server team with the necessary files to compile on our server for the first time. However they're used to working with web application files, not website files.
Normally they are given the source code and a batch file that compiles the code into deployment directories and then they just move the files to the server from there. I'm pretty sure that the other teams use deployment packages to do this, which obviously isn't an option for a website.
My question is, what would be the equivalent steps for getting the source for a website ready to deploy vs a web application? I have published the website to a separate folder and this has rendered what I think is the equivalent in many ways, but I wanted to make sure.
Also, is it possible to publish certain parts of a website without others?
Please with-hold all the comments about how I should be using a web application instead, google seems to assume that's all that's used out there too.
Thanks!
There isn't much to deploying a web site other than copying the source files to a directory in IIS. It will compile the site automatically on the first page request.
I agree with Britton. I personally prefer web application but with the web site project you have 2 options.
Either a) Upload all the files (including the .vb or .cs files) and the web server will compile on the fly. OR, you can publish to a separate folder locally on your machine, and then upload that folder. I would do the publish if you don't want anyone seeing your source code.
I noticed one weird thing today, and I'll appreciate your input on this.
I was assigned to work on a VB.NET project. I took the project files from the server locally.
I opened Visual Studio and then did open project, the project loaded in the solution and I did build, I got errors, pls check screenshot:
http://gyazo.com/3fe2ea4d5ff8fd073355d43160861e70.png?1348166929
2nd try, I opened Visual Studio and instead open project, I did open website, I selected the folder where the files are located and then open website. I build the solution, it says build succeded and the website runs fine in the browser.
Now I want to know why that's happening, why when I am trying to open as a project I am getting errors, and when I am opening as a website, website starts ok.
Thanks in advance, Laziale
In VS, Projects and Websites are different - a Project is a collection of files managed by a *.proj file (e.g. *.csproj, *.vcproj, *.vbproj), whereas a Website is just a filesystem folder without much in the way of project management metadata.
The second main difference is that Websites have a different Build process - unless you explicitly opt-in to pre-compilation the project is not compiled at design-time, instead everything is compiled by the webserver at runtime, which means you need to distribute all of your source code.
It also means that compile-time errors are harder to detect. You will get the same errors in a Website as in a Project, it just means you need to perform a live website action that uses the same error-prone *.vb files, and you'll get a lovely YSoD error then (rather than in the IDE before you publish it).
"Websites" were introduced in VS2005 as an "easier" alternative to VS2003's ASP.NET Web Applications, but there was a lot of backlash from developers - I wouldn't be surprised if they removed it from a future VS release.
I'm a total newbie to SVN and haven't been able to find an answer for the following situation.
I have an ASP .NET 2.0 web app that I am developing. I am using my local IIS as the development web server (i.e. not the Visual Studio web development server). My development environment is VS2005, Vista, IIS7, TortoiseSVN / AnkhSVN. VisualSVN is installed on the server.
My .sln files and class libraries, etc. are located in the **C:\Localsource\Projects\ProjectName** folder, and my .aspx files are in my **C:\inetpub\wwwroot\ProjectName** folder.
I can set up the repository for **C:\Localsource\Projects\ProjectName** fine, but can't think of a way to set it up for the IIS folder as well in the same repository.
What's the best way for dealing with this development environment in SVN?
Many thanks,
Ant
In a solution in Visual Studio you can have a class library project which is usually in a directory underneath the .sln file.
In this case he also has a web project within the solution but NOT underneath the .sln file in the file directory structure.
He will be attaching to this project via HTTP not via local file path.
IIS will manage this as http://localhost/webapp and by default will place it in c:\inetpub\wwwroot\webapp. The files in webapp folder will not be in the repo as they arent in the hierachy of the solution and the class library. This is his question how to sort it out.
My answer is to move http://localhost/webapp to point to a folder that is underneath the .sln file and adjacent to the class library directory then it can all go in the repo.
Seperating the class library and the the webapp is best practice to aide code re-use and decoupling the logic from the web site.
Can you not just point IIS to C:\Localsource\Projects\ProjectName and set the permissions?
Hmmm - Good point. It was set up like this when I got here, and Visual Studio always creates websites in the wwwroot folder, so I assumed wwwroot was just where they had to go.
Maybe I'll have to think about doing a little rearranging...
Thanks!
The IIS folder is not the output of the code base it is part of the application. It's not CGI output or anything but actually the scripts to run the app!
This is the .aspx pages that will have user controls and HTML to actually run the application. Its part of the applciation but split away from VS Studio solution.
The easiest way is to have a solution and then C:\Localsource\Projects\ProjectName\WEBSITE.
Point IIS at that folder as well.
OK, I may be being stupid here but.. Why do you need to add the IIS folder (i.e. the output of the code base) to your repository?
Update
I think I should clarify this a bit more.. What I mean to say is I am not sure why the ASPX is seperate from the project anyway? What is wrong with an Web Project and n Class Library Projects in a Solution, added to your repository.. You then publish on each new release..
If it is simply a case of "it might be easier to roll back the published output" then so be it, I was just curious as I have not seen many people actually work that way.
Deployment of solutions in this structure would be a lot easier as well..
I think you might want to separate this into two problems, following this recommendation from Dillorscroft.
First, with regard to the material on your development server that is published to the production site, I think you need version control for that. First so you can roll back any page, and you can also decide when you have a stable level of the development site that you want to extract to production. (I would get that from the source control system into a site image and then synchronize that image with the production site.)
So, for the first part, we are talking about versioning the web pages and all of the custom server-side material that supports the web site.
Secondly, With regard to the development of components that are used on the site, they need their own development projects, since it is the result that goes to the development site, not all of the source, libraries, etc. that the component is built with. So these will have their own project development tree (think of it as if you were building a library that is to be used by other development projects, although in this case the other projects are web pages). So the only thing that should show up in IIS is the "deployed" component to the development site.
There seem to be three critical questions for you:
How development of tests that need to go against the web site is handled and where that is version controlled (assuming they do not belong on the web site itself)
How easily you can arrange to make sure that all content on the development web site is kept under version control and checked-in and -out appropriately. (This has to do with the tools you use to edit web pages and other server-side gunk other than components developed off to the side.)
Easily taking developed components from the projects that produce them to the development site and have them be checked-in there.
My solution to (2) and to version control of the development web site is to use Visual Source Safe integration with IIS and FrontPage extensions that places the site under version control. Components produced from other development projects are mapped to the server project by VSS sharing.
For SVN, I speculate that (1) you want to see if there is an SVN adapter that IIS will recognize as an external source-control system and, either way, (2) have a discipline that takes delivery of components from their construction projects into the overall web site project.
Rob,
Why do you consider an .aspx file an output of the code base?
It is part of the code base. It's not an output after compilation for instance.
Just wondered?