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/
Related
I have a WPF app that I am planning on deploying with the Windows Application Packaging Project in Visual Studio that makes the MSIX bundle for installations and future updates. The installer automatically installs the app in C:\Program Files\WindowsApps. This is fine until the program needs to cache some data or it needs to modify the appsettings file since the app does not have permission to get to these resources.
Is there a setting I can change in the packaging properties/manifest so it can install somewhere else so I can avoid these problems?
Indeed, only the Windows can write in %ProgramFiles%\WindowsApps when installing the msix package (by design). If your app is writing log files or other data inside the installation folder it will crash.
You need to either update your code to write to %AppData% or, if you don’t have access to the code, use the Package Support Framework to fix it. You can read more about here:
Package Support Framework (aka PSF)
The PSF brings support for API redirection and hooking. Thus, you can fix an app that failed to write a file in the installation folder (this is no longer allowed) and redirects it to a recommended location, or maybe simply update the app’s working directory.
As mentioned above, you cannot write in the install location of an MSIX package - this is by design.
For apps that are no longer under active developer indeed using the Packafe Support Framework is the only way to fix them. However, from what I see you are preparing to launch the app, so you have access to its code.
In this scenario, it is recommended you save all your app settings in the AppData\Roaming folder. For apps deployed as MSIX Windows will automatically redirect it under the Packages folder, but that is handled automatically by the OS, so you don't need to worry about it. More details below.
How to save data under AppData\Roaming instead of AppData\Local\Packages
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.
I recently made an app for Windows Phone 8, and now I want to be able to run it on older devices with WP7.x as well. Is this possible without having to make a whole new Visual Studio project targeting WP7 instead of WP8? I targeted WP8 to make sure I was not held back on available features, but I don't think I ended up using any features that are not available in WP7 anyway, so now I would like to extend with WP7.x compatibility. Any hints as to how this can be achieved as easily as possible?
Although there's no automated way to "revert" a WP8 project to a WP7 project, it is possible to do it manually, by editing the .csproj file.
I don't have my Windows 8 system handy currently so I can't say for sure which items were involved but looking at the project file for a WP7 project, I (seem to) recall adjusting all or some of the the following lines:
<SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>
<TargetFrameworkProfile>WindowsPhone71</TargetFrameworkProfile>
<TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight for Phone\$(TargetFrameworkVersion)\Microsoft.Silverlight.$(TargetFrameworkProfile).Overrides.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight for Phone\$(TargetFrameworkVersion)\Microsoft.Silverlight.CSharp.targets" />
If memory serves, the WP8 project file contains similar lines, and they just need to be replaced with ones above. A comparison between a WP7 project file and WP8 project file should get you on your way. Of course, there might be dependencies that need to be removed or added too.
Otherwise, there's always the option to start a completely new project :)
You need to create a new WP7 project. There may be a way to edit you project and solution files but it would be quicket to just create a new WP7 project and add your existing code to t.
Btw. you should do it the other way around, start with WP7 and upgrade the project to WP8 only if you need the (very few) new features in WP8.
You will inevitably have to create another project that targets WP7.x
But that can be relatively easy, especially if you don't use WP8-only features.
To improve maintainability, you should consider sharing reusable code files between projects, for example by taking advantage of the "Add as link" functionality of Visual Studio.
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
I have make one application Cocoa using XCode. Now I want to make setup file of project. So other user can install this project directly in his system.
In short, the polite way is to build your app with the Release Configuration, put it into a Disk image with Disk Utility or zip it up, then put it on a server and have people download it.
If you want a longer and more detailed answer, read Apple's Software Distribution Guide.