I took over a web application project that reference dlls. The solution has the actual project as well as the class libraries used to create the DLL. I need to make changes to the web application and deploy to production. I'm use to deploying asp.net website as well as classic asp which was very straight forward, Just copy the files.
I need help to understand the compilation and deployment process. Here is some questions:
1) Class library(DLL) changed; do I just compile that class library project and move the Dll only.
2) Web application project changed and the dll stayed the same; what files do I move.
Also, if someone can clarify how DLLs version are handled when deployed. I'm use to the old way of unregistering /registering the DLLs and this is not the case right now. I'm worried about having multiple copies of the DLL on the same box.
Any help or reading reference would be appreciated.
Jamal
When you are manually deploying in that fashion it is very easy to make a mistake (forget to copy a related file). It's happened to me before.
I recommend that you make use of the publish feature in Visual Studio.
You can right click on the web app and from the context menu select 'Publish'. I normally publish to a local folder (You could publish to your server directly) and then use an FTP client such as FileZilla to actually deploy ( I've had some issues deploying directly from Visual Studio).
When you upload using FileZilla you can specify how you wish to handle existing file overwrites.
I use the option: 'Overwrite if source file newer'. That way deployment is fast (only the files that have changed are depoyed) and safe as we cannot miss a file.
To answer your questions:
1) yes, it is sufficient to deploy the class library but only if it remains binary compatible with the old one (Easy to make mistakes here).
2) You need to deploy the files that changed (dll's, aspx, cshtml, etc...). If the class library dll's have not changed you do not need to redeploy them.
Follow the steps above and you should be fine.
It sounds like you're talking about a precompiled .net application. The app is compiled using Aspnet_compiler.exe, and the new DLLs are copied to the host.
The DLLs don't have to be registered, IIS "knows" what to do with a precompiled .net app. It's pretty much just drop-and-go; not unlike copying the .aspx files directly.
You are able to update a subset of the DLLs (e.g., the class library). There are several modes available that allow you to compile all or part of the application.
When you change a DLL, often times you can just drop it right in assuming you aren't referencing by a specific version number. Generally to be on the safe side, I copy the entire website out again when changing DLLs. Its not strictly necessary, but its probably the easiest method if your website isn't too large.
If you're changing a file that is not deployed in its compiled form (.aspx, .aspx.cs, .cs files in the App_Code folder) you can just update that specific file and restart IIS for good measure.
Generally speaking, if a dependent assembly changed you can just deploy the new assembly. However, if ANY of the interfaces to that assembly changed OR there are other corresponding changes to the web application then you'll have to deploy the whole thing.
That said, I've seen shops that require a full recompile, deployment, and testing even if just one line of code inside a dependent assembly changed.
The full deployment part is pretty easy.
Right click on the web project and click Publish.
Publish either directly to the web server (I don't recommend this) or publish it to a local directory.
Make any config changes necessary for the production push.
If you publish to a local directory, copy the compiled files to your production server.
Some people say to delete the production files first, then copy. Others say copy to a new directory and repoint IIS to the new directory. You'll have to see what works for you.
Now, one thing web apps give you is config transformations. This means that you can let the compiler make config changes depending on the environment you are publishing to. I highly recommend you research and use these. It makes bad pushes much less likely.
Related
I have a big solution with 30 projects of which 2 are web projects (MVC and WebAPI) with a bunch of background class library projects.
I have visual studio set up to host the web projects in IIS.
If I do a clean build, followed by a full build of the entire solution, then accessing both projects via a browser works fine. (they are in diff folders and hosted on diff 'domains' in iis)
If I make NO code changes, simply rebuild one of the 2 web projects, the OTHER one stops working.
To be clear, rebuilding the WebAPI project causes the MVC project to have errors. And vice versa.
The error I get is saying that System.Web.Http.Formatter is not found. The detail says that the located assembly version is different from the reference version. Checking the bin folder shows that that is not the case.
Make sure that all the solution's resources are up to date. If you use Nuget, update all packages in all projects (back up first!). It sounds like you have a version mismatch, where functionality is missing in DLLs copied to the output directory for the solution. It may involve changing some entries in the Web.config of each project, but without access to the code, it's hard to know for sure.
Report back once you've updated every library, and made sure the versions match across all projects in the solution.
In addition to Apache's and Steve's suggestions, I'd also recommend deleting the files in your Temporary ASP.NET Files directory. If you're curious here's a good write-up of what the contents of that folder are for.
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
We are using TFS and VS 2010.
I have been working on a project that is using TFS as source control.
I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.
When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.
What did I do wrong here? How can I include those referenced DLLs in source control.
Do I need to add all these dlls to my project before referencing them? when I referenced them, I just browsed to where they were on my file system.
I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.
Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.
The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.
I created a "ThirdPartyDLL" folder in my project folder in which I copied all the extra DLLs into it. I then went into source explorer and added those DLLs into the team foundation server so I could be sure I'm using the correct versions of the DLLS for specific versions of my application (and so everyone else is on the exact same page as I am).
View - other windows - Source coontrol explorer
Right click project folder - add items to folder
You won't be able to select a specific folder with DLLs in it, but instead you can select the individual DLL files within the folder. You will then see the "ThirdPartyDLL" folder appear in that window.
Once this is done, those dlls are in the team foundation source control. Whenever a dev checks in, they will get the most current version of the DLLs.
Don't forget to remove the old references in your app and change them to your thirdpartydll folder.
I used to copy the DLLs into the bin folder but the issue I ran into was when the DLLs got upgraded. Initially when my project was small it wasn't a big deal. Now that I have multiple DLLs and applications that I created it became very difficult to maintain consistent versions of DLLs outside my project. My best example is the licensing dll I purchased. When this got upgraded all applications and libraries needed to be on the same version. If I forgot one then I had weird issues or the application just stopped working. Now that I have everything in one folder, I make the change once and everything is upgraded.
Hope this helps.
Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.
I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.
My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.
Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.
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)
I have a C# console application written in Visual Studio 2008.
Usually I just build the application and then copy the files from the 'Release' folder but this time trying to do it 'properly' by publishing the application.
I went through the 'Publish Wizard' and end up with a 'Setup.exe' file in the specified folder. When running this setup file on another computer the install fails and indicates via a error message that:
Cannot download the application. The Application is missing required files...
When I select the 'details' button the error log shows that the program was trying to download files from the last version directory (ie 1_0_0_4).
What am I doing wrong? (aside from being tired...)
Show I de-activate the version auto-incrementing?
Unless you have a valid reason to do so, I would abandon the publishing and just go back to the XCopy installation. (And by Valid, I mean something other than someone told you that it's the "proper" way to do it.) I base this advice on the following arguments:
We used ClickOnce for all our WinForms apps for a while, but eventually it got to be more trouble than it was worth. For one thing, you need to deal with the security certificates. We had issues when we replaced a server with a new one with a different name, then we had issues when we replaced our development machines, etc.
You said this is a console application. ClickOnce publication seems to be overkill for a simple console application unless there are third party dependencies that you need to include in your install.
Don't get me wrong, I liked using ClickOnce for the ease of putting updates out there, and we use it still when it's the best option. However, in your situation, it looks to me like XCopy deployment should be sufficient for a simple console application.
Not knowing what you choose in the wizard, web or CD, the setup.exe file needs to be able to reference it's installation files. If using the CD method, you will notice in the output directory you revision directories, e.g. 1_0_0_4, where each revision of your app is kept. I agree with #David_Stratton, and unless you really need to use one-click publishing, don't. Just use xcopy (robocopy), zipfiles, etc. It will greatly reduce your stress levels down the road.
Everything David Stratton has stated is correct. ClickOnce is overkill for what you're trying to do, and publishing through Visual Studio has always given me headaches.
I might recommend taking a look at NSIS if you're looking for generating an installer for others. It's relatively simple to generate full installers that merely grab files from your /Release/ directory, with plenty of sample code for getting an installer working quickly. Once you have your working script, making your installers are as simple as a right-click and clicking compile.