I come from a PHP/Rails background where deploying a website often means FTP/Checkout of the source code in the correct directory on the web server.
However, I've been asked to develop an ASP.NET website and some people have advised me to "Publish" the site instead of copying over the source code directly. Apparently, this converts the codebehind (.cs) files into compiled DLL's etc.
My application does not contain any specific secretive business logic. It's a common shopping cart app. My question is if this is a good idea? How does not making the C# code reside on the server make the app more secure?
ASP.NET code will always be compiled - either:
At run-time - you can copy .ASPX and
.CS files to the server. When a page
is requested the .ASPX and .CS files
will be compiled on-the-fly. The
ASP.NET run-time will create a DLL
containing the compiled code (this
lives in a folder called Temporary
ASP.NET files and the location
depends on the version of .NET
you're using).
Pre-compiled - you can choose to compile your code before deploying it to your server. This is what the Publish command does in Visual Studio. It compiles your .ASPX and .CS files into (one or more) DLLs that are then uploaded to the web server.
Personally, I don't think there's much of a security benefit from deploying pre-compiled code (unless you're obfuscating your pre-compiled DLLs).
That said I prefer it for these benefits:
It seems tidier, at least to me, than having a bunch of .CS files littered in a folder
There's a small performance benefit of not having to do C# compilation. Note your code will still need to be JITed from IL to native code and this still incurs the initial request performance hit (unless you use new ASP.NET 4.0 and IIS 7.5 features or something else).
The Publish feature lets you package your application up for deployment to other environments (testing, pre-production, production, etc.)
Note: coming from Rails/PHP you might like to keep on deploying both .ASPX and .CS files to your server. The benefit is that it's easier to modify a running application in a way you may be used to doing. This isn't a great practice if you're following a rigorous deployment lifecycle but it can be useful in some cases.
I can make one addition to the precompiling though, which has been mostly about security and performance; compiler checks!! Without precompiling you can easily upload some code file containing errors but not find out before 13 days later when the first user hits the page using this code-file. This is due to the fact that asp.net will only compile one file at a time whenever its needed.
With precompiling ALL the files will be compiled and ALL compiler errors be caught right away.
Thats all about precompiling though but publishing is not just about that.
Another important factor is the steps you can instruct msbuild to execute during publish. Maybe the most important thing is web.config transformation which you can read about here http://msdn.microsoft.com/en-us/library/dd465318.aspx. Basically you can create a transformation file that during publishing will replace/add/remove values from your web.config based on the publishing target.
Your c# code is still residing on the server, it's just residing as a compiled code instead in the form of a script as you are used to in PHP/Rails.
In PHP, rails or classic ASP, you write scripts and xcopy / ftp to your webserver. PHP interpreter then parses the script everytime a web request comes in vs. in asp.net the code is compiled and then copied to the webserver, so when a web request comes in, the execution is much faster.
Think of it broadly as deploying an .exe file on the server vs. writing the program in a text file and making a compiler parse the text file and running it every time.
It has nothing to do with being more secure or not.
Btw - How's life after Bluebells School :-)
Yes, it's more about compiling than anything else. For the website to be able to run, the C# code must be compiled and that is what the publish step does, together with transferring it to a specific location.
The version of the website you have on your desktop is a development version, most likely with debug versions of the compiled code. With the publish step however, you should generate a release versions of the compiled code which also improves performance.
The publish step of ASP.net can be compared to creating an installer of a normal Windows application and, when published to an operational server, the install step combined.
Related
I am a newbie to asp.net. I recently publish an asps site from Visual Studio using C#, but I realised that the scripts I wrote for the buttons, links, etc to interact with my database on local machine is missing when I publish the pages.
Do I have to rewrite the code for the pages now on the web host?
Your advice is needed.
Thanks
It's really hard to answer such a question, no details, no code, and things disappearing mysteriously. However, given that you're newbie and from the description that you have, I will try to give you some tips that will hopefully set you in the right direction.
Firstly, I don't know exactly what you mean by "script", so I will assume you're referring to what is called code-behind. ASP.Net is different from many other web application frameworks in that it is compiled. So you have the front-end of your aspx pages which has a mixture of HTML and ASP server-side controls, and then linked to each aspx page you have an aspx.cs code file for the code-behind.
Now, when you're ready to upload your project to the hosting, you should use the Build => Publish menu. This will compile your project in Release mode. All the aspx.cs pages will be compiled into a dll, so you will not see them among the file that are uploaded to the hosting, and you cannot modify them. The aspx pages are typically not compiled (although you can configure that), so you will see them and you can still modify them.
As for the database connection, when you're writing your code, you typically connect a local database on your computer. You should have the connection string in the web.config file in the root folder of your project. However, the connection string for the hosted database is likely to be different, so make sure you have the correct connection string for the hosted database in the web.config before you upload your code to the hosting.
I think this will answer your question. It's a setting on a file level, available on properties (F5) for the file:
Visual Studio 2010 Web Publish missing a file
Once you set it and republish, the file will show up in the publish location.
I have an App Service in my Azure account which I deployed with Visual Studio Publish wizard. Is it possible to restore the deployed solution locally (in Visual Studio) from the Azure App Service?
When you publish an app to an App Service (web app), just your code is published, not the Visual Studio project / solution files. So no, unless you somehow forcibly packaged (or maybe ftp'd) a copy of your solution files, they won't be available for download.
It's fairly trivial to pull the app down to a local machine though, since Web App has built-in ftp. Just don't count on being able to retrieve source code for languages such as c# and Java (since usually just the dll/jar files are published).
I want to mention one thing which might be helpful if your application is .NET. There are many .NET Decompilation tools today(Reflector, ILSPY, JustDecompile etc.) that can open a .NET DLL and let you view the code (the best one being Telerik's JustDecompile which can create a PROJECT out of a .DLL file or any .NET Assembly)
The code will not look EXACTLY like the one you created but can get you pretty close. Definitely worth a try if you lost your code and looking for some way to get it. This will only work if the code was not obfuscated in the first place. There might some rework required but you can get somewhat close.
I developed a site in asp.net using C# as the language.
I have debugged it and no more errors can be found and can also view the page from a browser.
I would like to host this site and direct a client to it for demo purposes but am having a problem each time I publish my site. The publishing only does away with all my .aspx.cs files but I don't see any .exe file that I can install or send to my hosting provider.
I would like to know if this what I am experiencing is normal or there are settings I need to do in my visual studio 2013 ultimate edition for these tasks to be performed?
Kindly advise me on the way forward
ASP.NET applications (not "ASP.NET websites") are compiled into a .dll file in your bin folder, which is then deployed on to the server.
Your .aspx/.cshtml1 files reference compiled classes and types contained within this DLL, thus eliminating the need for source files.
There won't be any .exe files, you need to deploy your project to a web server, like IIS. Check out this link.
I have an asp.net application that I currently deploy to 4 different environments on the client's servers. At the moment we deploy by copying over individual assemblies and content files but the whole process is time consuming and error prone. Basically I'd like a method of preparing the application for deployment that will give me a folder containing the application (no source code etc). No IIS changes are required. It would be good if I could specify different webconfigs for different environments.
I've looked at msbuild, msdeploy, etc and I'm not even sure which is the right tool for the job. I'm tempted to go with a batch file that copies only certain file extensions but I'm sure there must be a better way of doing this. Any help please?
Take a look at the Visual Studio Publish Web Site feature.
What is the best strategy for making changes to a specific file within a C# .NET project and a DEV server and then moving that file to a different environment, say server B? I noticed it always wants me to recompile on the destination server and I figured I was doing something wrong because I didn't think I would have to (plus the server isn't in-house so it is really slow and time consuming).
Any suggestions or strategies you or your company uses would be appreciated.
Make sure you are using a Web Application project where it compiles a DLL, not web site which uses loose code files.
You could use a source code versioning system like Subversion.
use a source control program for source files (like SubVersion) and Cruise Control for binaries built out of those files...
For web application development my experience has been:
Developers have a development environment on their local machines that is attached to source control
A DEV web server with shares to the projects created allows developers to COPY files to the web application folders manually.
A TEST web server where MSI installations ONLY are used to distribute the changes for UAT
A PROD web server where MSI installations ONLY are used to distribute the UAT approved MSI
The size of projects I am involved with usually makes build scripts overkill, most times a project is being worked on it is built many times for debugging etc.