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.
Related
I have two VS projects. One is to install something, the other project is an installer, basically a nice neat installer with pictures that calls the first project at the end to run the setup.exe.
Now, I want to publish this so that, someone can, on their computer, not mine, they can open my folder, open the setup file and it'll install fine, without errors like my setup.exe file being on my machine and not theirs.
Is there a way in Visual Studio where I can include that setup.exe file in my resources folder or what?
I was also thinking, when you say publish, there is a server option? I just have no idea how that works. We have a sharepoint website where we keep all our information.
Please and thank you.
Have you considered bundling your executables (installer and application) in to a ZIP file and having that downloadable? It wont launch automatically but it is a neater and preferred approach (from a security standpoint). If you have a thick client application, have you considered ClickOnce as a better option for deployment?
For neater and more secure options, look at the deploying section in here for best practice.
For your set up, you need two actions:
1) Download the setup file, use WebClient.DownloadFile and store it locally.
Alternatively, include it in the project and set the copylocal attribute so that it is part of the deployed binaries. Alternatively, this post tells you how to add it to the resource.
2) Use Process.Start("{Path to your downloaded setup.exe}") to launch the set up from your installer.
Not that I haven't done any searching, but the result always leads one back to the MSDN recommendations that "all will be taken care of" if you use their Publish Wizard and "publish" your click-once application. And of course nothing is ever taken care of.
Invariably I do this: I make a CD based application, have it as "Create the setup to install prerequisite components" that's the default. Do my publish. And BAM, pretty much 90% of the people who were told "here's my first test version" write back immediately and say "it didn't install" and then we view the details and it's near impossible to ascertain what in the world is the problem. Once the result was that one guy had placed the setup files so deep in a directory structure that was why it failed, this was literally found by accidental web search/lucky peek at a suggestion comment.
Seriously, there's no iron clad way for a developer to say "I can determine exactly the full list of prerequisites; as well as the minimum system for this application", so that they can construct their published click-once application ONCE and once only?
My inclination here is to "check all prerequisites" and then un-check the ones it gripes at me about; like it will say "you can't both pick A and B, or B includes A so that's irrelevant.
It's great that I can customize the list of prerequisites, but since I don't "know" that list; what I'm asking is how I determine that list?
It should be fairly easy to determine your prerequisites. Depending on which version of .net you are programming in will tell you which version they should have as a prerequisite(most likely 3.5/4 at this point). Any external libraries will need to have the DLLs packed in, as those will not be detected by the prerequisites wizard.
You list of prerequisites should be fairly obvious if your the one who wrote the program. Which libraries did you use? Include those that do not have installers, and if shipping on a CD, you might as well include the .net installer for the version you are using in code.
I've seen click-once fail quite a few different ways. One is nesting to deeply, which is typically a rare occurrence. Second is checking the network for updates. I've had issues where click-once won't install if it is set to check for updates on startup, but it can't contact the update server. You'll need to sort that one out depending on your environment. I also saw one situation where a co-worker wrote an app that simply would not install via click-once, it would crash every time. I resolved the issue by correcting some very very bad code, but the app would deploy fine in a ZIP file.
Lastly, does your application NEED an installer? Is it a large package with many dependencies and complex directory structure, or is it just a few files and folders that will happily run from any directory? If it is the latter, you may be better off distributing a ZIP file installer and being done with it. Also, do you plan on making use of the auto-update features of click-once? That is really the only reason I ever use it, and if you don't plan on taking advantage(or can't) it loses much of its appeal.
I found this particular solution. And thank you for answers, they were helpful.
For this case Visual Basic PowerPacks 10.0 was a prerequisite. I don't know why it was a prerequisite because I wrote no VB code. It may be because I chose a custom ICON image. I did try to take it out and the app then installed, but crashed.
The setup was configured to download the installations for anything it needed.
That process was happening, but failing.
We downloaded the VBPP setup.exe from Microsoft, included that with the release folder, and told those who would be installing to run that setup first and then run the setup for our app. That made it work.
Before it was clear that the VBPP install was starting, it asked for acceptance of the EULA. The "install" also looked different than from when we downloaded and ran the VBPP setup.exe separately.
Is there a way to publish a VS2012 App (WPF) to an .exe without any installer? I know how to use ClickOnce installers but i was wondering if it could be taken one step furthur.
Many small programs seem to come in a .rar with some app files and an .exe that runs and doesn't have to install. Is this possible in VS2012? (or 2010)
Yes, sure, it's possible. Just compile you app in Release mode and take all you have in Release folder.
This is possible with Visual Studio 2012 depending on your needs and your approach to developing your application. I'll list a couple options, but don't take this as being exhaustive as there are many ways to accomplish the same thing. I'm assuming you want a "1 click" solution for the user.
You can embed all of your application's resources into the application allowing your users to be able to simply download or copy the .exe and run it from anywhere and it "just works".
Pros: The only method that gives you what you asked for. A single .exe without the need for an installer.
Cons: You can't edit any of the embedded resources without a recompilation of the application. You also can't store user settings for this same reason (though you could silently create a settings file in App_Data or similar).
Self extracting archive. This is the WinRAR method you mentioned in your question. You embed your application into a self-extracting archive which is set to extract to the users Temp directory or App_Data (or similar) and to launch your exe upon successful extraction.
Pros: You get the ability to update your resources as they aren't embedded into your actual application.
Cons: Technically, this is still an installer; albeit a very lightweight and self-contained one.
There are more, such as click-once; etc., but this explained the general idea.
Note: The correct .NET version will need to be installed for these to work as simply as I described.
Here are the concerns I can think of that an installer takes care of that you would need to worry about:
The correct .NET framework already exists.
Any assemblies that you reference from the GAC are already installed.
You don't need any custom registry entries or permissions to be granted.
Your app doesn't access anything that would keep it from working in a "low trust" environment when the user is not running as admin.
There are surely more, but basically if your app is self-contained and does not use any external resources and the correct .NET framework is installed, you should be able to just copy your build output and go.
I'm developing an open source C# application. For awhile now, I've been using a basic .NET installer I coded myself. However, with a recent change, that is no longer practical for me, as I'd have to add a large number of files to the installer - and they may change with each release. A ZIP file is also not practical.
I've done some checking online, I see a lot of MSI, ClickOnce, Self-extracting ZIPs, and (imo the most promising) the NSIS system. None of them seem to exactly fit my needs, so I'm looking for advice on which system to use.
Actual installing of my program is very simple. Basically, I just need to copy the bin\Release directory (and all subdirs) to the client's computer. I've been achieving this somewhat ad-hoc, by embedding every file in my .NET installer, and maintaining a file table of what goes where.
Unfortunately, I just localized my app. I now have 30+ .resx files (Which are compiled to dlls and placed into MORE subdirectories by Visual Studio) and, obviously, it's impractical to add 30+ folders and DLLs to my installer. Hence why I'm on this search.
There's also a few other requirements:
The installer should search predefined directories for a specified .exe. (My app is designed to be a drop in replacement) If the .exe is not found, it should prompt for its location
The installer should verify that "OldApp.exe.bak" exists. If not, it should rename "OldApp.exe" to "OldApp.exe.bak"
The installer should update files. Ie, if "Culture.de.dll" hasn't changed, the installer will leave it alone.
The installer should work with all Windows versions of all .NET IDEs (VS, SharpDevelop, Mono, ect) but does not need to work on other platforms.
When I build the solution, the installer should be automatically regenerated. In other words, it should be run-able for by "Post-build" section.
The installer generation must be able to be added to a source code repo. This is so that anyone who downloads the source of my app can compile the installer as well.
Sorry for the long post, I figured it was better to post more than less.
I'd recommend SharpSetup. It combines WiX and C# for a pretty flexible implementation. Not much I've found it can't accomplish.
We use WIX extensively: http://wix.codeplex.com/
You may have to customize your installers with some exit routines to do things out of the ordinary, but there are hooks in Windows Installer framework that let you do that.
You can put these definition files (XML) in your source control, and you can configure a build to execute the installation. However, anyone that gets your source would need to have the WIX utilities installed.
I would recommend NSIS. From my experience any installer feature that I have required has been covered in NSIS documentation or community examples. I can't comment on NSIS integration with Visual Studio as I use NSIS integrated with my Jenkins build server. There appears to be a free Visual Studio Add-In called Visual & Installer which provides NSIS integration with Visual Studio. I have not personally used it but it appears to be currently actively developed so might be worth checking out.
WIX is a good one. According to Wikipedia, it is used by Microsoft to produce installers for some of their own products.
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)