I changed jobs this year, so due to that i switched from Java to C#.In both jobs I work/worked on a large application that is deployed to a server and exposes various webservices.
With the Java job, an ant build process created a .ear file that contained a .war file and other objects. This .ear file was deployed by copying it into a directory within a JBoss/tomcat server. I understood the process fairly well.
With the C# job, I press a green triangle "play" button in Visual Studio and the application is compiled and somehow deployed to IIS, and Visual Studio then starts up a web browser pointing to the application's URL. I don't completely understand what is happening under the hood during this process. We have a build server that creates production builds that go out to production servers, but I don't understand a) what artifacts are produced by the build process, and b) how are those build artifacts deployed to IIS.
I would like to understand the process well enough to manually drive builds and deployments, re-automate the process, and also troubleshoot and modify our existing build and deploy process. I can drive a build with msbuild, but what does that produce, and how would I get it deployed onto another machine's IIS installation?
What happens when you hit Run (the green triangle) is probably not the best example, because it is using a specialized form of IIS (sometimes called Cassini) hosted within Visual Studio with a debugger attached.
To get a clearer picture of what happens when deploying, use the Publish tool to deploy to a folder on your desktop. In that folder you will see what is essentially the web root. Your project, minus any code files, and a bin directory with the compiled binaries.
Typically only static files such as html, css, and png, etc. will be deployed, while any code files won't. By default Visual Studio "knows" which files to build into the binary, and which to simply copy to the output folder (and which to ignore). But you can change this in cases where you need to override that behavior, or you have a file type VS doesn't know about. In your solution explorer, right click on a file, select properties. In the properties window for that file you'll see "build action", which shows what VS will do with that file.
Hope that helps.
Just add a note.
So,
If you are working with ASP.NET Website, it should enough to manually copy it to publish folder
If you are working with ASP.NET Web Application, so before publish it should be compiled. All compile operations is performed by MSBuild - command line utility to buld .net projects. But how MSBuild can understand, what it should build and in what way? Easy - there special files with instructions for MSBuild - is solution files (example howto build project from command line "C:\...\MSBuild.exe" /maxcpucount:10 MyAwesomeSolution.sln). Solution file contains references to project files (and build order for projects, etc), project files contains references to files, which included in project (and type of project - library/console/web app/etc, and framework version, and action for each file - build/content/resource, etc). If some file does not included to project, it will be ignored.
So, when you press green button, firstly VS will run MSBuild to build your solution. Inside solution should be written, which project will be used as starting point and what should be done before/after build. Inside project there information, howto debug project (via IIS, IIS express or smthg else).
So, when we working with some CI server, to compile our solution is enough to run MSBuild on CI server with path to solution. Ofcource, to publish compiled solution via CI, additional scripts should be written (to cpy files, etc).
Also, if you want to publish you website to some location, you can create "publish profile". It allows you to publis your website to IIS, FTP, etc, but you have to press "publish" button manually (right click on web project => publish)
Related
I wrote a fairly simple application with C#/.NET and can't figure out a good way to publish it. It's a sort of a "tool" that users would only run once, or run every few months. Because of this, I'm hoping that there is a way I could deploy it where it wouldn't need installing to run (it could just be run by double-clicking an EXE file straight after downloading).
However, it still needs (somehow) to include the correct version of .NET, libraries, etc. so it will run correctly. I know this is included when using ClickOnce, but that still installs the application onto the user's computer.
Is there a way this can be done?
EDIT - \bin\Debug
myAppName.application
myAppName.exe
myAppName.exe.config
myAppName.exe.manifest
myAppName.pdb
myAppName.vshost.application
myAppName.vshost.exe
myAppName.vshost.exe.config
myAppName.vshost.exe.manifest
extraLibrary.dll
as well as two folders
app.publish
Resources
It is possible and is deceptively easy:
"Publish" the application (to, say, some folder on drive C), either from menu Build or from the project's properties → Publish. This will create an installer for a ClickOnce application.
But instead of using the produced installer, find the produced files (the EXE file and the .config, .manifest, and .application files, along with any DLL files, etc.) - they are all in the same folder and typically in the bin\Debug folder below the project file (.csproj).
Zip that folder (leave out any *.vhost.* files and the app.publish folder (they are not needed), and the .pdb files unless you foresee debugging directly on your user's system (for example, by remote control)), and provide it to the users.
An added advantage is that, as a ClickOnce application, it does not require administrative privileges to run (if your application follows the normal guidelines for which folders to use for application data, etc.).
As for .NET, you can check for the minimum required version of .NET being installed (or at all) in the application (most users will already have it installed) and present a dialog with a link to the download page on the Microsoft website (or point to one of your pages that could redirect to the Microsoft page - this makes it more robust if the Microsoft URL change). As it is a small utility, you could target .NET 2.0 to reduce a user's probability to install .NET.
It works. We use this method during development and test to avoid constantly uninstalling and installing the application and still being quite close to how the final application will run.
First, you need to publish the file by:
BUILD -> PUBLISH or by right clicking project on Solution Explorer -> properties -> publish or select project in Solution Explorer and press Alt + Enter
NOTE: if you are using Visual Studio 2013 then in properties you have to go to BUILD and then you have to disable define DEBUG constant and define TRACE constant and you are ready to go.
Save your file to a particular folder.
Find the produced files (the EXE file and the .config, .manifest, and .application files, along with any DLL files, etc.) - they are all in the same folder and type in the bin\Debug folder below the project file (.csproj).
In Visual Studio they are in the Application Files folder and inside that, you just need the .exe and dll files.
(You have to delete ClickOnce and other files and then make this folder a zip file and distribute it.)
NOTE: The ClickOnce application does install the project to the system, but it has one advantage. You DO NOT require administrative privileges here to run (if your application follows the normal guidelines for which folders to use for application data, etc.).
I want to update an application with modified code in some files,So Is it enough to update the .dll file extension and the necessary files or Do i need to replace the whole project?
You probably never need to replace the whole project. After you recompile, look at what DLLs were modified. You shouldn't need to replace every DLL in your bin, but you may need to replace each DLL that represents a project in your solution, depending on the dependencies of your solution.
So you will need to move over the DLLs that changed, as well as any other files that were modified (obviously excluding .cs, etc).
Though ideally, you will just use the "Publish" feature in Visual Studio, which automatically will copy over any (and only) necessary modified files. Doing it manually leaves too much room for error. Also (ideally) you will have a test server to publish with Debug settings so you can test, and then you publish with Release settings to your live server.
How to: Deploy a Web Project Using One-Click Publish in Visual Studio
So I made a C# program, and its great and all (its a Windows Form Application). The issue with it, is I don't know how to use it outside of the debug mode form. How do I publish it? My target goal is to create a two folders, put a shortcut to the application in one, along with the other folder which will contain the application and all outside programs (some of the buttons link to batch files). Then I'd want to be able to put it in a RAR compressed file, and upload it online for others to download it.
How do I publish it so that happens? How do I take it out of debug mode?
Go into your project folder, then navigate to /bin/Release. If there's an EXE file with the title of your project in there, copy it somewhere (along with any DLLs that you may have linked) and there's your program. If it's not there, first try Build -> Compile Solution in Visual Studio. If it's still not there, navigate instead to /bin/Debug and do the same thing. Then, copy all your batch files into another folder, put them into the same folder, and RAR it.
P.S. Try not to use RAR, few people can extract them. Use ZIP or SEA (self-extracting archive) if at all possible.
First off, you need to build your application in Release mode, in Visual Studio simply change the drop down near the top of the window to "Release." This will create a bin/Release directory where your sources are located. The folder will contain an EXE for your application and DLLs you need to include. It could (and probably will) include some debugging *.PDB files that you do not want to include -- as those include debugging information.
Copy the contents of that directory somewhere and RAR it up.
Building in x86 Mode
(You should only do this if you have a specific reason to)
If your application uses 3rd party DLLs that are not 64-bit compatible, you may need to do a release build in x86 mode. To do that, click the "Any CPU" drop down and click "New Configuration" (or something like that) and follow the steps to add x86. Then build with the x86 -- Release setting. That will output x86 binaries to a bin/x86/Release folder where your sources are located.
The Preferred Soltuion
Most users are going to prefer some form of automatic installer instead of a simple RAR or ZIP. Visual Studio (Standard/Pro) can create self installing MSIs that do all the work for you. A basic overview is here. You can add shortcuts/etc using the wizards Visual Studio provides.
If you need an even more robust installer you could check out solutions such as InnoSetup or NSIS
To build your application in Release mode instead of Debug, go to the Build menu and select Configuration Manager.
Change the Active soluction configuration to Release. Now, when you build your solution, it will put the executable in the /bin/Release folder.
If you need to automatically perform certain actions once the solution is built, like packaging into a RAR or ZIP archive and copying the distributable to another folder, then check out post-build actions.
After Visual Studio 2010 , Microsoft remove Make setup utility facility from the visual studio and,we have to downlorad that plugin seperatly from
Get InstallShield Limited Edition for Visual Studio
You Have to fill the application
After intalation, goto
Visual Studio-->New Project-->Other Project type-->Setup and Development
You will see follwing screen
Now you can goto InstallShield setup utility and change the things as you requirement.
add all file in debug folder of your project in follwing interface and build solution,
Final setup will locate in your setup folder-->Express\CD_ROM\DiskImages\DISK1**
hope this will help you
Similar to this question
Compile to a stand-alone executable (.exe) in Visual Studio
But nothing there works for me.
I've written an app that is very simple in C#. I want this to compile to a stand alone exe file, but I can't seem to find the proper settings to do this. Everything compiles into a publish folder and there is only the setup/install files.
Thanks!
You just compile it. In the bin\Release (or bin\Debug) folder, the .exe will be in there.
If you're asking how to make an executable which does not rely on the .NET framework at all, then that's a lot harder and you'll need to purchase something like RemoteSoft's Salamader. In general, it's not really worth the bother: Windows Vista comes with .NET framework 2.0 pre-installed already so if you're worried about that, you can just target the 2.0 framework (then only XP users would have to install the framework).
I am using visual studio 2010 to make a program on SMSC Server. What you have to do is go to build-->publish. you will be asked be asked to few simple things and the location where you want to store your application, browse the location where you want to put it.
I hope this is what you are looking for
Are you sure you selected Console Application? I'm running VS 2010 and with the vanilla settings a C# console app builds to \bin\debug. Try to create a new Console Application project, with the language set to C#. Build the project, and go to Project/[Console Application 1]Properties. In the Build tab, what is the Output path? It should default to bin\debug, unless you have some restricted settings on your workstation,etc. Also review the build output window and see if any errors are being thrown - in which case nothing will be built to the output folder, of course...
You can use the files from debug folder,however if you look at app debug informations with some inspection software,you can clearly see "Symbols File Name" which can reveals not wanted informations in path to the original exe file.
Press the start button in visual studio. Then go to the location where your solution is stored and open the folder of your main project then the bin folder. If your application was running in debug mode then go to the debug folder. If running in release mode then go to the release folder. You should find your exe there.
You can get single file EXE after build the console application
your Application folder - > bin folder -> there will have lot of files
there is need 2 files must and other referenced dlls
1. IMG_PDF_CONVERSION [this is my application name, take your application name]
2. IMG_PDF_CONVERSION.exe [this is supporting configure file]
3. your refered dll's
then you can move that 3(exe, configure file, refered dll's) dll to any folder that's it
if you click on 1st IMG_PDF_CONVERSION it will execute the application cool way
any calcification please ask your queries.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)