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?
Related
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.
What are the types of deployment we have in asp.net?
Till now what I am doing?
I use to publish my website in any folder than copy paste the compiled file to the inetpub folder [where my website is configured with the IIS]. I am not sure what kind of deployment this is, is it XCOPY? But I am not using any command line tool.
So you have the following options
xcopy deployment
Compile your asp.net application and copy all the files to your server. You can do this by using FTP or shared directories. (Or anything else to transfer files.)
WebDeploy
You have the possibility to deploy your asp.net webpage directly form your Visual Studio. If you go to "Build" and you choose "Publish Web". To be able to to do this you have to configure your server before. But this works automatically after you have set up everything. It's very handy since your deployment becomes easy to rebuild.
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Web Setup - Installer
Visual Studio provide also the option to build an installer. This works like installing usual software on your windows computer with the installer wizard. (See the link)
http://weblogs.asp.net/scottgu/archive/2007/06/15/tip-trick-creating-packaged-asp-net-setup-programs-with-vs-2005.aspx
Manage multiple server
There is also a way of managing the deployment of multiple servers. It seems to be a bit more complicated but could be interesting for professionals. (Check out on Google Microsoft Web Farm Framework 2.0
To answer your question: yes, what you are using is called xcopy deployment. Even though you do not type xcopy . ... it is still a 'plain copy' and therefore called xcopy deployment.
The problem is, that when I commit project directory, there is uploaded everything including source code.
Not really sure why you want to upload via FTP? You shouldn't commit your own compiled binaries to source control for deployment though.
You could take a look at AppHarbor, just push your code with git and it will be build and deployed automatically.
more about AppHarbor
Real alternatives to Windows Azure PaaS (web role)?
Does it matter? Since asp.net pages can be compiled on the server, having source files on the web server is sometimes normal so IIS knows not to allow access to them.
That said, uploading output binaries into source control is generally a bad idea - it is better to do the deployment from your build server.
Actually, this is kind of hard.
For months, I've tried to automatize our deployment, without absolute success. For my experience, I can see only way to do that:
Have a build server on your deployment machine (or same network)
A build server will pull out your code from repository, say, once per minute and will check for modifications. If there's modifications, it will execute the build scripts related to this project. I suggest you to use TeamCity, because it is very easy to use compared to CruiseControl (I'm not sure if you can use Git with TFS). You can program your build server for build your solution or project and after, you can execute an msbuild script to copy the files to the production folder (e.g: c:\inetpub\yourapp or \\my_server\inetpub\yourapp). You can use MSBuild's Copy Task to do that.
UPDATE 1: I didn't tried, but if helps, you can push to an FTP server using git-ftp
UPDATE 2: Seems that some guy did some workarounds and successfully deployed his app using git and FTP.
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
Is there a security risk associated with using the option that copies "All project files" when publishing a web application into a production environment? I normally use the option "Only files needed to run this application" which does not copy the source code to the server.
I am the only person with access to the production server. There is also no issue with cluttering the production server as there isn't much on it. In fact I don't mind having all the source files be kept on the server together with the binaries.
Is there any security issue with this?
If no one can get access to the production server then there is no security risk with this option. However this is a pretty big if! I can’t see any real benefit from using the All project files or All files in the source project folder options – these don’t even allow you to update the web application in place on the production server which might be useful in some situations. I would stick to the Only files needed to run this application option just to be save.