I made a setup project for my windows forms application and then installed it. It properly created a shortcut on desktop. Now when I double click it to open, it shows a progress bar like thing saying Configuring application. After that, my windows form appears and runs normally.
I have no clue why this is happening. My earlier version for the same application was running properly with o. Also if I install the previous version, it starts normally without any problems. Only the setup files that I am creating now are showing this problem.
Any one having any clue...
You created a ClickOnce installation. You probably wanted to create a standard Setup Project. IIRC, there was some issue with this type of project in Visual Studio 2010, as in the project type is being depreciated, but I can't seem to find anything about that now.
Other alternatives are using WiX or the limited edition of InstallShield.
Oddly enough, the ClickOnce installer is pretty good, assuming you have the infrastructure to support it (a spot on the web where you place updates) and don't mind the nonstandard behavior (that weird dialog on start). Frankly, installer technologies right now in the .NET world suck. They're all extremely complicated and fail to insulate the developer from the intricacies of how installers work with Windows.
To turn off ClickOnce, IIRC, do the following:
Uncheck "Sign the ClickOnce manifests" on the Signing tab
Uncheck "Enable ClickOnce security settings" from the security tab
remove any references to "System.Deployment" from your projects
Related
I'm trying to convert a WPF oneclick installed application and so everything should be pretty straight forward. However, whenever I run the debug project, I get
'The parameter is incorrect'
in a message box popup and I can never run the app.
This happens for my app while trying to debug, all the samples from github, and even the DAC application from the Windows Store. The error pops up even once the app is installed and showing in my application list.
I'm on the latest build of the Creators Update.
There are various errors in the event viewers, but they seem to be a common occurence for WinRT apps.
Any ideas at all?
If you have the WPF project in VS2017, I'd recommend to package directly from VS without using the DAC. see the article for more information https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net
The problem appears to be related to the May Security Update. I restored Windows to the factory defaults and everything works fine.
However, once I install the the May Security Update to address this bug with Sql Server and Filestreams, the Desktop Bridge Debugging project stops working.
I'm going to throw out a random guess that it's related to the Microsoft Malicious Software Removal Tool, as the event viewer logs mentioned an issue with the 'parameter is incorrect' referring to the Microsoft.MRT.
Of course it could be anything, and as only 7500 people have even downloaded the Desktop Bridge Debugging project in the first place, I doubt it's high on the list of Microsoft Developer Priorities.
And to be completely honest, it's really probably my fault for not rewriting the app as a UWP app, after rewriting it as a Windows Forms app, and as a Silverlight app, and as a WPF app and on and on and on. Although, I'm not sure how many glasses of Kool Aid are left in the punch bowl for me.
I've been using Inspect.exe from the Windows SDK to examine the properties of a WinForms application but noticed that I didn't see any of the properties (for example, the AutomationId) whilst running the application from Visual Studio (F5 to run.) However, if I ran the .exe from the bin\debug folder I could see the properties fine.
The source I was using was example code downloaded from UI Automation Custom Provider Samples - Part 3.
I'm wondering why this happened since I'm sure another machine that I had tried this on worked fine and I wasted time poking around in debug mode wondering why my UI Automation properties weren't visible. Obviously there's a workaround but I'd like to understand why this was happening and have a record of the problem for other people to find!
I've struck upon the answer - because I had launched Visual Studio as Administrator but the Inspect.exe tool as standard user then the properties being reported back were a sub-set of what I should have seen. As soon as I launched Inspect.exe as Administrator it worked!
I have a WPF C# desktop application that will need to be deployed as MSI (Windows Installer deployment, not ClickOnce deployment) in VS2010. My application will generate SQL CE database in run-time, manipulate Excel Workbook, and receive/transmit data from/to COM Port - so I don't know what is the appropriate way to deploy such an application.
I am looking at Windows Installer Deployment Tasks which doesn't help me to get started.
Could anyone show me some resources that give instructions on how to deploy an application as an MSI installer?
If you don't want ClickOnce, then you'll probably need to create your own MSI. In that case, you can use:
The built-in Setup project type in Visual Studio. It does a decent job but has limitations. Works very well if you don't have many dependencies or custom actions.
A commercial tool like InstallShield
WIX (Windows Installer XML)
I've tried both 1 and 3. While WIX has a little bit of a learning curve, it is a very rich way to do what you want to do. There is a fair bit of documentation available and some very nice "out of the box" wizard sequences to handle your standard install scenarios (licenses, feature selection, dependencies, etc). WIX does have some VS integration that works quite well.
You can find out more on WIX at http://wix.sourceforge.net/
Note:
The VS setup project can do custom actions, and install dependencies, but you have to use custom actions. If you want to parameterize the custom actions, then you'll need to find the not-so-intuitive instructions on that topic.
The other limitation of the VS setup project is that the setup project can only be compiled to an MSI by VS (devenv.exe). That means that the MSI cannot be compiled on a build server unless you install Visual Studio there too. This was a show stopper for me, so I switched to WIX and was very happy with the result.
For those like me who found this post after searching high and low for how to deploy an MSI these days, you now need an extension as the visual studio team removed the built in startup project functionality. You now need to download the Visual Studio Installer Projects extension.
See this user voice post for discussion of the removal, and here is a link to the extension.
Useful for people looking for a quick solution to generating an MSI through Visual Studio rather than getting deep into Wix (although if you need more advanced deployment options, definitely go that route).
Configure your WPF application to publish as a ClickOnce application. You can do that in the 'Publish' tab of the project properties.
If you use the 'Publish Wizard' (by clicking on the aptly named button on the properties page) you can specify (on the second page) that the user will install 'From a CD-ROM or DVD-ROM'. This option will produce a setup.exe file in the publish sub-folder of your project output directory. This setup.exe program when launched by your user will install the WPF application. You may choose to include an update functionality (but you don't have to).
The ClickOnce settings also allow you to include additional files (e.g., your SQL CE database file) and pre-requisites if necessary.
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.