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.
Related
So the current situation is, a client will download an .msi bundle generated from wix, perform the install and enter some specific configuration details afterwards into the application (a windows service/console).
I was looking to streamline this process so all the client has to do is run the installer (no configuration needed), so I was wondering if anyone had any experience with a similar situation.
This is how i image the workflow would run.
User logs into multi-tenant web application => User clicks a download button => Web server collects tenant information => Web server passes configuration into wix (as a build parameter?) => msi is generated with the configuration embeded => User downloads the generated .msi and the world keeps spinning.
Now there are a few things i am unsure of, so here are my questions.
How would you go about running the wix installer from the web application? It's written in C# so would it just launch a cmd window and run msbuild?
If 1. is possible, how would it look/function in Visual Studio. I'm assuming the installer project/installer asset project would both need to be in the build output of the web application, is it possible to copy the raw files into the output? <= is that even a good practice?
It just doesn't seem practical to me, so if anyone has any suggestions on how this can be accomplished, either how I described above or any other methods then I am open to ideas!
Just to clarify, the main goal is to "generate a windows installer at runtime with a tenant configuration embedded"
You can do it from C# for sure. Take a look at the Wix extensions for CakeBuild for example: https://github.com/cake-build/cake/tree/33b83fdbc24a7d3d1bafc4cd7c7df0a204162e3b/src/Cake.Common/Tools/WiX
As to packaging 'content' files up with your web application you can do that too, the wix project files are no different than any other asset as far as the website is concerned.
Also, to run processes from a dot net application there's a bunch of work to do around redirecting and logging the output, you may wish to look into some of the process handling packages on Nuget that can do this for you.
Performance may be an issue for you, plus ways to secure the downloadable MSI in case you only want one user to get it. You may also need to look into code signing if you aren't already. Other than that it should be fairly straightforward.
I've been trying to research this the last couple of days and it doesn't seem like there is very good support for beginners. All video tutorials I find don't answer the questions I'm asking.
What I want:
I have an application I've written with .NET 4.6.1 in Visual Studio 2015 and I want to distribute an .exe that automatically checks if there are updates. It seems like this is exactly what OneClick is intended to do.
Where I'm at right now:
I want to publish to a shared drive among multiple people. It seems like I put that file path in the "Publishing Folder Location" which produces Setup.exe, MyApp.application, publish.htm, and Application Files. When you go to publish.htm there is an install button that downloads Setup.exe.
Where I'm stuck:
When you download the Setup.exe file onto your local machine and try running it gives an error. The details say it wasn't able to find the MyApp.application file. It seems that file is responsible for knowing what version of MyApp is currently installed on the users machine so that it can be compared to the download location (in my case the shared drive) to see if updates are available.
What am I missing? Do I misunderstand the purpose of OneClick publishing? Shouldn't users be able to visit the publish.htm once to get an .exe and that .exe is used to launch my application and look for updates first? I really appreciate any insight on this topic!
PS I've read over all the MSDN documentation, but it isn't user friendly to beginners in my opinion. Or maybe I'm just slow : )
You understand it exactly right, but when a user navigates to the html page, it downloads multiple files. The .exe, the .application and other supporting files.
You are correct in assuming ClickOnce is what you want. What I've found is the .net dependencies are very particular when using click once. You have to make sure each machine has the correct version of the framework and then they can use the htm site.
What I prefer doing is distributing the .application file to the users machine and just letting them run that. It will check for updates on the server every time it is ran and copy all the necessary decencies to the users Local directory.
You have to direct the users to the .application-File.
That one is responible for versioning (Updating) and executing your Application.
If you execute the .exe it will look for the .application-file to find the infos about the version, which should be installed/downloaded.
NOTE
Not all Browsers (in case of internet/intranet-deployment) support ClickOnce. But there are extensions for almost every browser
Say I have a c# web application project in a TFS Team Solution that I am deploying to a development server (IIS7). I want to be able to promote only certain code changes to a test server, and then later promote ONLY those changes to the production server.
So for example changes to a web user control and a javascript file should be promoted, but a change to a web form should not be promoted.
Using the deployment feature in Visual Studio seems to be an all-or-nothing proposition.
Short of manually selecting files to copy/paste, or write some kind of app that compares files in a target and source directory, list files that are different, and lets you select source files to promote, what do teams usually do in this situation?
In short: how can I reliably promote select files/code from environment to environment without also including other changes that should not be promoted?
Create two branches in TFS, one for development and one for production.
Merge dev->production only changes that you need.
Create deployment packages from production branch.
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.
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.