Some background to my problem...
We are currently using ClickOnce to deploy part of our solution which was working a treat until we encountered a scenario where we are now required to have multiple instances of our application installed on the same PC. We are able to achieve this internally and have this working perfectly as we know what instances we have so our build process will update AssemblyName to include the instance name before publishing the installer, this means we are able to have multiple instances on our PCs internally (ie, test, live and demo etc).
Our external deployment process is slightly different, we take one of the ClickOnce installers created in our build (along with all our other components that make up our application) and as the ClickOnce installer is deployed on a server we update the app.config along with the manifest files and resign so they now have client specific details. If a client chooses to have multiple instances of our product installed the ClickOnce will now fail when a second instance is installed on a desktop PC as all instances share the same assemble name.
So finally to the question, does anyone know of a way to update the manifest etc after the clickonce package has been created to allow multiple instances to be installed? We could go down the route of building many clickOnce installers but I dont think this will really work for us, is there perhaps an alternative to ClickOnce which provides a similar upgrade experience for non-admin users?
Hopefully someone will be able to share their experiences and help me resolve this.
Thanks in advance
Doug
I don't know of another technology that allows such a simple auto update process. So sticking with ClickOnce... I think this link might be useful. It explains what you need to do to have the same app installed twice. Essentially changing the assembly name and product name should do it.
Hope that helps.
Greg
Related
I have read in some threads that MSIX will start to support also windows services from the January build. But I only seem to find information of how to migrate an existing installer containing a service to MSIX. How should I do if I want to create a completely new MSIX bundle from scratch, containing a UWP project and a Windows Service? I can´t seem to find no information about this no matter how much i search. If someone have succeeded in this it would be vary appriciated to hear how you did this!
I have a sollution in visual studio containing a UWP project and a Windows Service Project. I try to simply add those two projects to a new windows application packaging project but no matter how I do this I only manage to install the UWP app from the created bundle. Is it still not possible to include the Service project in my MSIX? I get no errors when I build my sollution. I have simply added the UWP project and the service under "Applications" in my windows Application Packaging project.
I have also read that background tasks may be prefered to services in msix packages. But I am afraid that a background task may be a bit too limitied for my intentions. My main requirement for a service is not to have something running in the background, but to access functions outside the UWP sandbox. Like USB storage and other functionality. But maybe this can be achieved by a background task as well?
Maybe the MSIX sollution is a bad idea in my case, do you think I need to relay on some other packaging sollution for my projects instead? Like Wix or similar? I have very little experience in packaging installations so I prefer a tool that is as simple as possible.
The recommendation for apps in development is to use background tasks instead of trying to add a Windows Service.
For the case where you're trying to access content outside the UWP container, you can consider adding a desktop extension component to your UWP package and then using that for your required functionality. Have a look at this blog post for more details - https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-1/
I wrote a DLL (with a COM interface) and wonder if I can use ClickOnce to deploy it on end-user machines (to be called using CreateObject("My.DllClass") from the user VBasic app. All the documentation that I've read for ClickOnce (and the abortive attempts that I've made) seem to indicate that a real app (exe, etc) is required for ClickOnce -- it can't deploy a single DLL (and some txt files) and get the DLL registered for COM use on the target machine.
Q1. Is my understanding correct?
Q2. Is my best alternative to learn the Wix Installer?
Thank you
Q1: Yes, your ClickOnce application must have at least one launchable executable file. It's minimal requirement. But you can add any .net executable file there.
Q2: Yes/no. I will try to describe some things for you here. It'll let you make a right decision in your choose. Here is my point of view your task if you gonna choose a ClickOnce technology.
Abbreviate: ClickOnce application = Your.dll + dotNet-Some.exe
At the first you need to know a ClickOnce application locating in Users\[CurrentUser]\AppData\Local\Apps\2.0 after get installed by user. You can't effect on location, so if your client PC have more then one users, then second one must install your application for your self again. As me know your COM assembly must be registered by regasm.exe, there for your Some.exe can on launch register your dll by regasm.exe or some WinAPI functionality, so executable file won't be useless in this way.
Major question is update process, you must track your clickonce build number at the first, and for update operation user must launch your Some.exe for check and now workarounds from here. If this update process if fine, then you need re-register your assembly again (because clickonce add new folder for updated assembly) and user will be ready for use your class.
In the case of MSI package you have full control of install process, but you need always deliver this packages to your clients. Wix is good, if you are .NET developer take a look on WixSharp - let you create installer much more faster and have a lot of examples
If you don't gonna publish your ClickOnce application from Visual Studio then you can use Mage.exe / MageUI.exe for ClickOnce application preparation or use my builder utility from here second download link.
I hope what i said was a bit useful.
We were hoping to create a setup project which would allow for a pick-n-mix approach to which files were included for each local client installation.
Basically we've got a core setup.exe which we only want to build once, and which contains most of the product. But for each client there's a custom DLL which fits their solution. The custom DLL is loaded dynamically at runtime by the software and that's working fine. The problem is in the setup.
Of course we could 1) write an individual custom Setup.exe for each client too 2) keep a single setup.exe and customise it each time we want to do a build for the customer
But both those approaches are problematic.
For reasons too complicated to go into, the below approach is going to be the safest and most straightforward:
Maintain a single setup project
add all the custom DLLs to the setup project but set them to PackageAs=Loose (and also Vital=False)
then, every time we want to rollout the install files to the customer we send the setup files minus all the custom DLLs except his own
Our problem is that this approach falls down when you run the setup.exe on the client. Everything's fine except that the setup.exe still knows about all the DLLs you've quietly removed from the file system for this customer. And the installer starts shouting if it doesn't find all the files where it expects to find them:
Actually, this isn't a problem because you can hit Continue and then everything works fine.
Except that actually it is a problem because if you're selling to Pepsi (we're not, but say we were) you sort of don't want the installer to moan that it can't find CocaCola.foo.dll in the middle of its install.
We almost want an additional setting of Extremely Loose for the PackageAs field so that the installer knows not to even worry if it doesn't find the file.
Is there a solution within our existing approach without having to learn a third-party installer?
It sounds like your optional components should be created as Merge Modules and then you'd need a specific installer created that includes only certain modules. It sounds like you have some client specific libraries you don't want exposed to your other clients. Of course this means you'll need a build for each client, but that is something that could be automated.
I have a C# Visual Studio console application with a service reference. The company providing the service offers two API's one for test and one for live. They are supposed to be essentially the same service but with different URL's to different servers.
When I right click the service reference and choose Configure Service Reference, I am able to enter the the URL for the live service; and my project compiles properly.
I am new to this and am not really sure if I should be reconfiguring the service or if I should be deleting it and re-adding it in? I don't know if there are .config files I should be changing or cleaning manually.
So I guess my question is - are there pitfalls or better practices for this process that I should be aware of?
Any advice greatly appreciated. Thank you.
I have worked with Service References myself and so far never had any problem with just updating the service reference. If you like/need to change the configuration, it is possible by editing the .config file that gets generated
I am trying to deploy an application using ClickOnce. The problem is, I am saving user generated files in the application's working directory. Now when the user installs the next version of the application, his old files will no longer be available to him. What is the best workaround for this problem - or does this mean I have to roll my own installer!
thanks!
Look into using isolated storage rather than the application's working directory.
This post should help you out.
When Windows Vista came out and developers could no longer store data in Program Files, Microsoft recommended using LocalApplicationData. We store a lot of cached data there, under a folder with our application's name. I wrote a blog entry showing exactly how to do this if you're interested. I call it Where do I put my data to keep it safe from ClickOnce updates?