I have a clickonce application that has a console application foo.exe which simply launches a windows forms application bar.exe. I deployed it using visual studio to a network share. Life happened and I no longer have the project that I used to publish the original clickonce application. I need to replace the bar.exe windows froms application.
What is a good way to accomplish this?
Use MageUI. Make sure you back up your full deployment before doing anything. Then replace the bar.exe file
Open the application manifest (the one without the .application extension), save, and re-sign. Then open the deployment manifest (the one with the .application extension), save, and re-sign.
You could use the command line version of Mage as well, but for a one-off scenario, the UI version will be easier.
Related
I've created a wpf application. Now I need to make an application to download it from a web site to various client machines with no server software. What are the essential requirements that need to be installed from the web to the client in order for the application to work? I am very new to this and am learning as i go along
As stated by the others you may publish your application using clickonce. An alternative approuch is to use a third party installer like wise(yee old .msi is removed from newer visual studios). MS wants you to use clickonce for deployment it may be done manually using mage, through MageUI or visual studio directly. I only use mage.exe for deployment of WPF and XBAP applications, it's nice if you have a buildserver set up and all. Just make some scripts for the deployment that you may reuse, once deployed check your manifest file to see what's included and not.
General information about clickonce.
Mage.exe located in your windows sdk for manually deployment
MageUI, useless for any live production envirnoment...
Hope it helps you some, I know this can be a pain.
Cheers,
Stian
I'm trying to use the LocBaml way (this might be my mistake) to localize a WPF application, but this application is deployed with ClickOnce and the publishing process doesn't pick up the localized .resource.dll.
I do add the files to my ClickOnce manifest, and I can see that this part works because when I launch the application, I get an error saying that the application can't find fr\LocalizationTest.resource.dll. (So at least it knows it should be there...)
The normal way to include a file in a ClickOnce application is simply to add it in the Project Properties -> Publish -> Application Files menu, but my localized resources are not in there.
What can I do ?
Turns out adding a dummy Resources.fr.resx in the Properties folder fixed the problem. With that the publishing process picked up the translated .dll and the ClickOnce application worked as expected.
Does anyone know how to specifically include a winforms setup project to be included in the code_drop folder generated when running UppercuTs zip.bat? With the default settings my web applications and WCF services are included, as are the dll's for the solutions core, but not my winforms application/installer
I was just playing around with UppercuT last night, and I ran into the same question.
One tip I found for putting console apps and windows services into the code_drop is to use this Nuget package in your console/windows service projects:
http://nuget.org/packages/publishedapplications
See this for more info:
http://devlicio.us/blogs/rob_reynolds/archive/2011/03/22/published-applications-aka-publishedapplications.aspx
Using this will cause your console/windows service projects to be "published" similary to how a web app is published in the code_drop. However, this isn't what you're asking for, just wanted to point it out if its useful. This also doesn't work for installers.
If your installers are using the default Visual Studio setup projects (.vdproj projects), I haven't tried that, so I can't help there. I do know that MSBuild refuses to build those types of projects (not sure why...), so you might be better off using WiX or another installer technology. You can do an automated build on a vdproj if you run the build by calling devenv.exe directly from the command line, but you can't build those with MSBuild. I did try adding a WiX setup project to my sln, and UppercuT will build the Wix setup project and drop the .msi in the "build_output" folder, but it doesn't copy it over to the code_drop. My thought would be to add a custom post build step to just copy that file over from build_output to code_drop. I haven't had a chance to figure out the logic in the build scripts to see how it chooses which files to copy from build_output to code_drop. If I figure anything out, I'll update this answer.
I have a problem with ClickOnce publishing of a WPF application.
If the application is built (debug or release), it is running correctly.
Application published by ClickOnce crashes.
I tried to change Target Platform. Sometimes this change helps to solve problems, but not every time (1 of 20 cases).
I have Visual Studio 2008 and the project has been upgraded from Visual Studio 2005.
Any ideas?
Thank you in advance!
On the machine where the application is installed, drill down in the user profile to the ClickOnce cache, and look for the cached application files. The folder will have the exe and all of the assemblies, etc., in it. Our winform app creates two folders, xxxx_tion is the one the application runs from.
Find the exe file and double-click on it to run it. This essentially runs the application without the ClickOnce-ness of it all. If it crashes, then it is not a ClickOnce problem per se, it is a problem with your application.
I would check and make sure you are deploying all of the files you need, you don't have references to multiple versions of the same dll, you don't have circular references, etc.
Good luck,
RobinDotNet
There is a long discussion on http://social.msdn.microsoft.com/forums/en-US/wpf/thread/3e6909ef-2ab1-4b77-8bc2-796c065a6219/
Solution that worked for me (send by pindurav on page above):
I rebuild whole solution
close visual studio
open visual studio, open project and directly publish without building.
= no app.xaml exception
I'm developing a Windows Form application that will typically minimize to the system tray. Being new to .net, what would the easiest approach be for packaging/deplopyment that allows:
The application ensure it puts itself into the startup menu, or something equivalent to this.
Easy updates—like those apps that periodically check for updates. When there is an update to install, it should automatically download it via the internet and install it.
I read that using the ClickOnce/standard deployment approach that ClickOnce won't work because it doesn't support the ability to put the application in the START-UP Menu during installation. Is that true? If so, what should I use?
Thanks.
ClickOnce apps can (and automatically are) placed in the start menu. You can optionally have a shortcut placed to them on the desktop as well.
ClickOnce apps cannot be installed in the "system start up" folder; that is, cause them to start when Windows starts. Don't confuse the "start up" folder with the Start Menu.
If you're just starting out with .NET, I'd recommend ClickOnce. It saves lots of installation headaches and automates everything from updates, to start menu shortcuts, to desktop shortcuts, to file associations. It's a decent technology. The deployment couldn't be simpler. In Visual Studio, just click Build->Deploy, specify where you want to deploy to (FTP, network share, etc.) and you're all set.
An ordinary Windows Installer project would do the trick. All the user needs to know how to do is click Run...Next...Next...Next...Finish.
Choosing Between ClickOnce and Windows Installer
http://msdn.microsoft.com/en-us/library/ms973805.aspx
Windows Installer provides the Start Menu support and easy updating features that you require. It also has the ability to check for updates.
I am less familiar with ClickOnce, but it does have some of the same features. An overview of the feature differences between Windows Installer and ClickOnce is here:
http://msdn.microsoft.com/en-us/library/142dbbz4.aspx
In particular, there are differences in the level of permissions granted to the installer, as well as driver installation and menu shortcut capabilities.