I have an app which makes specific files. Those files only can be opened by the app. Since we release updates often, sometimes users want to go to previous versions of the app to open old files. Hence, I should make a way to switch between different versions quickly by using Qt Installer Framework.
I think to upload different versions as repositories and let user select one of them.
User should have ability to select only one out of them, other
selections should be unchecked automatically.
Then Installer must uninstall the previous version and install the selected one instead.
I've searched and these two questions are more or less similar to my question.
https://forum.qt.io/topic/98000/qt-installer-framework-exclude-components
Switch between variants of component in Qt Installer Framework
Moreover, I have been through every single examples in Qt Installer Framework documentation.
Unfortunately, I didn't find a way to check/uncheck selection according to users selection and to uninstall and install accordingly.
Related
I wrote a WPF program using .NET 5, packed it into the MSIX bundle (Release, x86 and x64) as a framework-dependent package. Everything seems fine, but there is one very annoying thing: on the first run the app says ".NET runtime is missing, would you like to install it?”. If you click yes, the download page opens, where the user has to select the needed runtime, download, and install it. Not the best user experience, I'm thinking about how to improve it.
Is there an option to add .net 5 runtimes (x86 or x64 depending on the user system, or maybe both) as a dependency so it installed automatically?
I know I can define dependencies, but how can I find the right name for the needed dependency?
Also, I know it's possible to define custom install action but I haven't tried it yet, because I want to find a simpler solution. Looks like for that option I'll have to create a small app or script that will check if the needed runtime exists and if not - check the platform and ask the user to install the specific version of the runtime. Not the best user experience too.
Of course, I still have an option to go with self-contained, but I don't want to distribute so many megabytes of .net every time, especially given the fact that I expect frequent updates.
Luckily, I got an answer on techcommunity.microsoft.com
Thanks to Matteo Pagani:
if it's an application based on .NET Core / .NET 5 (as I seem to understand from the description), the suggested and best way to distribuite via MSIX is to use the self-deployment approach. Thanks to MSIX features like differential updates and single disk instance, you don't have to worry too much about the increased size, since the runtime will be downloaded only at the first install.
Dependencies are not a good fit because there are no packages for .net 5 yet.
Custom install actions are possible but more complicated, so I decided to go with self-contained.
Having some issues with the online installers, I would like to use the offline installers to create an installation with multiple Kits and versions. I would like to be able to switch between MinGW, Visual Studio and mobile targets just by switching between the Kits, and I would like to have the latest two Qt versions (5.4 and 5.5) available for choosing.
However, there are some issues with this:
The offline installers are only available with a single Kit. Installing the same version twice with different Kits to the same directory seems to mix up Qt Creator's available Kits, and the installation seems to replace the previous one in Windows' list of installed software.
Every single setup comes with its own Qt creator instance, and only there the Kits are available as desired. So when installing in seperate directories, a lot of duplicate stuff is installed.
I tried copying together kits from a few installations, but running a big installation, copying part of it and then patching the kit with the installer again seems to be a bit weird ...
Isn't there an easier way to get a consistent installation on Windows with the offline installers?
First of all, I believe this issue is not as big as I thought: Even the multiple Qt Creator installations that come with every offline installer do not create any bigger conflicts. The only thing that might happen with these: When starting different versions of Creator after each other, one might see conflicts with the settings files of QtCreator which are always stored in %APPDATA%/QtProject: Using an older version can corrupt the newer one.
That said, I believe the simplest way to work with different Qt Versions is to use a new installation folder for every Qt version, and to use a separate installation of QtCreator. Then one of course has to set up debuggers, Qt Versions and Kits manually for each new installation. The benefit of this is that one can also simply remove any version one doesn't need anymore - without risking to remove the used Qt Creator.
Qt creator automatically seems to detect and select appropriate help files + examples from the installed Qt versions.
Compared to using the online installer, the installation needs more space for the multiple Qt Creators, however installations are really separate from each other, so there is no risk in messing up anything by using the online installers again when a new version comes: the online installer only gives the latest two major versions with their latest minor version, and when changing from one minor version to another, one might want to compare results between these.
I need to store the release build of my Flash Builder (Flex) application in Subversion. When I try to add it to version control via Subclipse I get a warning telling me that I have asked to version control one or more resources that otherwise would have been ignored. Does anyone know why this is happening, and how I can get around it? I've gotten around this one time in the past by adding the build release's directory to the repository using another Subversion client, i.e. outside of Eclipse/Flash Builder, but when I rebuilt the release later I was unable to get Subclipse to see the changes between the base/head revisions and the new local versions of the build release files.
I realize that what I'm doing is non-standard and I suspect that there are default svn:ignore settings someplace which are causing this to happen, but I can't figure out where these are in order to modify/bypass them. Or maybe there's something else going on?
Thanks in advance for any insight and/or help with this issue.
This is an Eclipse-specific feature. Eclipse has a feature where files that are produced by compilers or generates inside Eclipse can be marked in Eclipse as "derived" resources. Eclipse team providers are supposed to ignore these files automatically. AFAIK, that is the only reason the feature exists.
So Subclipse still allows you to manually choose one of these files to version, but it warns you that you selected files that Eclipse said to ignore.
It is possible (but I have no idea) that Flex Builder has some setting to control whether or not it marks these files as derived.
In xcode 3 it was possible to configure specific option for building every single file of a project, like for example disabling specific warnings, thumb code generation and so on.
In xcode 4 such feature is not available, or at least not in an intuitive way. This is however supported, at least as a backward compatibility feature, in projects imported from xcode 3.x.
Does anyone knows a way to specify those settings without having to open the project back in older xcode or creating a project for every single file?
Select the project in the navigator, then select the target from the list. Select the Build Phases tab, then expand the Compile Sources phase. The Compiler Flags column is where you specify per-file compiler flags.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.