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
Related
I have a WPF app that works with local SQLite and Entity Framework Core. I want to distribute my app using ClickOnce.
Everything works fine when I run it using Visual Studio 2017. But app had a crash on a start when I used ClickOnce. The crash was so early so I couldn't even log the exception. After some time I found that in publish folder some dlls were missed. For example System.Runtime. All references are NuGet packages. Then I found that despite of I have a reference to the dlls in my project ClickOnce application files list doesn't contains it.
The only solution I have found for now is to add missed dlls as files in root of my project and set build action to Content. In ClickOnce application file dialog I set publish status to Include.
It works now but it looks like not the best way to do it. The question is why they are missed in the first place. More likely I missed something or I am not understand the root of the problem.
UPD:
You can find an example code here.
It works from Visual Studio but crashes on a start when you try to install it as ClickOnce application.
UPD: The problem was fixed in Visual Studio Professional version 15.6.1
There are two ways solving solve this.
At first, you have to go Properties → Publish → Application Files, and at this place, make your DLL files include in your project
But if it does not work, go to References and make the DLL file CopyLocal = False. You add a DLL file like Existing Item in your project and make them Copy Always.
It will work correctly.
But for your sample I watch this and I solved it. Look at this image:
You have four DLL files. You need do this for them:
System.Diagnostics.Tracing.dll
System.Reflection.dll
System.Runtime.dll
System.Runtime.Extensions.dll
At first go to your reference and make them Copy Local False:
Then go to the path of each DLL file and add them like Existing Item, and then make all of them Copy To Output Directory CopyAlways
Then Publish it and run it like in this picture. I run it from publish file and it works.
Even if you set the dll to copy local, the dll will not get copied over unless you actually use the dll in your code. You might try adding System.Runtime in your code somewhere like this maybe?
var dummytest = System.Runtime.GCSettings.IsServerGC;
Based on Issue 9 on https://blogs.msdn.microsoft.com/bclteam/p/asynctargetingpackkb/ I was able to do the following:
Symptom
ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Bcl or Microsoft.Bcl.Async packages may experience a TypeLoadException or other errors after being installed.
Resolution
This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:
Right-click on the project and choose Add Existing Item
Browse to the folder where the System.Runtime.dll lives
In the File name text box paste in the path of the file
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Runtime.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish
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)
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
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.
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)