What is the difference between publishing a website with visual studio and just copying the files over to the server? Is the only difference that the publish files are pre-compiled?
There is not much difference between "publish", and copying the files. Publish appears in a webapplication. The only difference really is publishing gives you the option to only include html and dll's, where as copying you would need to parse out source code manually. There is no full precompiling in the publish option, as Fully precompiled means no HTML at all; The aspx files are just placeholders; All html is in the compiled binaries.
I believe you are correct in your assumption. It has been my experience that the only difference is that published files are compiled. Visual Studio® 2008 Web Deployment Projects is a nice enhancement for customizing your build scripts for both your Websites and Web Applications.
Related
I normally do a file system publish on my asp web applications before deploying in them on the web root of my web server myself and visual studio packages my aspx pages seperately along with my apis and libraries into DLLs nicely.
I was wondering how to achieve the same effects with Team Build. As of now, I'm able to run build definitions with the default template and the output I'd gotten are just the binaries DLLs without any aspx pages being generated at all
http://postimg.org/image/occoo03zh/
However I'm getting just the DLLs without web pages in Team Build
http://postimg.org/image/mat7co6vp/
I had tried passing various MSBuild Arguments in hopes that it would have changed the output, but no luck thus far. Anyone knows the exact reasons and ways that I can resolve this? Is this output from TFS build normal?
It hasn't been resolved yet, any insights is very much appreciated.
Asp pages are not compiled, your compiled dll's will be outputted to the binaries directory, but your asp pages will be left in the sources directory. you will need to add a post build activity to copy your asp structure into the drop folder.
Can you confirm this by looking in the build workspace (on build server) and seeing if the structure is correct in the sources directory and that the dll's were created in the bin folder. if so you can then copy that whole structure.
You need to pass MSbuild some arguments to get it to generate the published website as you would see it with a file system publish. See here for something similar done with Visual Studio Online.
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
Loading it in VS 2010 throws many errors, though it does finally, albeit partially, load.
Also, the .PROJ file was not recognized by Windows at all, I opened the .SLN file in the /src folder but that threw tons of errors when loading up in VS web express 2010. Is that the problem? Do I need full version VS 2010?
Have you enlisted the full source code from Codeplex as described here? If you want to work with the source (eg. for module development) you should fetch the full source and not use the prebuilt package, which is intended for server deployment.
Also, I'd advise you to read this article about building Orchard from source. Visual Web Developer 2010 Express should work perfectly (as Orchard can be built without having VS at all).
It's ok that .proj file was not recognized - it's just an MSBuild XML file for automating the build process. You almost never have to touch those.
We have a main web application that references several other projects. Do you check-in .csproj/.sln files into source control? If so, do you use these files for msbuild or do you just include *.cs to build your dll? Does ILMerge help in any way with performance?
You should aim to check in everything that is needed so that someone can take a fresh install of Visual Studio, do a checkout, double-click the .sln file, build and be on their way.
.sln and .csproj are a no-brainer, in my opinion: what happens if you add a new file to the project: everybody would have to manually add the file to their project files if you didn't commit the .csproj file.
ILMerge - no. Not for web applications. Not for the rest either.
Checkin? What about letting visual studio handle it. Now, in general - source control without all relevant files is garbage ;) So, it should include stuff like the project and solution.
I am working with Team Foundation Server and Visual Studio 2008 for the first time. I had a web site project that was done with Visual Web Developer Express, which I have converted to a solution containing a Web Application Project, setup for TFS source control, etc etc.
TFS was having issues checking in/uploading some of my referenced DDLs, specifically AjaxControlToolKit, saying things like /bin/AjaxControlToolKit.pdb couldn't be found. I removed the reference, deleted everything it had in /bin (it had created lots of folders like /ar, /cs, /de, etc etc along with other files like /bin/AjaxControlTookKit.dll), then re-added the reference to AjaxControlToolKit. It will now upload, and works fine locally, but it didn't re-create anything in /bin. I have other references that work fine and have info in /bin (ie: /References/LinqKit.dll and /bin/LinqKit.dll) I cannot do a build on the server yet, but locally it works. So, will this work when its built on the server? Why didn't it recreate anything in the /bin folder? Is that something to do with Visual Web Developer Web Site vs Visual Studio Web Application/Solution? Any info is appreciated! Thanks.
References are references, not copies of the assemblies. Where are the assemblies you're trying to work with?
Typically, you'll want to check in third-party assemblies that you are not maintaining source. You'll then want to change the file references to point to the version from source control.
Of course, this means that all your developers and build machines will need to maintain the same folder structure on disk.
I have finally finished my web site. I published it, and I was surprised at the results. Although the App_Code compiled into a single DLL file, every page's code behind compiled into its own DLL file. How do I make it so that it is one DLL file?
Also, is it possible to compile everything (SubSonic, AJAX, etc.) into that same single DLL file?
You might prefer to use the web application project style for that.
You can use ILMerge to merge assemblies into one.
The way we do it is by adding a deployment project to our site:
http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx
To accomplish this you will have to covert your project into a Web Application Project (Supported in Visual Studio 2005 SP1 and Visual Studio 2008).
The process of converting is not that hard, but you will need to move everything out of the app_code folder, as WAP (Web Application Projects) projects do not have code inside app_code.
Once you do this, everything inside your project is compiled into a single DLL file, any external assemblies are still contained in their own DLL files though, but there are options around that as well.
We use build scripts for our websites and run the aspnet_merge.exe from the command line. Here's the MSDN page: http://msdn.microsoft.com/en-us/library/bb397866.aspx