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.
Related
Can I just replace the two old version realm frameworks to the new version ones? Or what should I do?
Yep! If you're not using a dependency manager like CocoaPods or Carthage, you just need to delete the old framework folders and copy the new ones into the same place. Xcode should be fine handling that the next time you attempt to build your project.
If you are using a dependency manager, then you just need to hit the update command in their command line tools, and it'll be taken care of automatically.
Please keep in mind that Realm 0.97 has completely removed all of its previously deprecated APIs, so if you were using any of those, you will get build errors, but they'll be very easy to fix.
I cam up with the same question and while looking around came up with a good solution. This is in addition to what TiM has pointed out. Also, a few things to keep in mind:
I upgraded from version 1.0 to 1.0.1: so there weren't many changes to the framework and commands I used in my app.
I didn't use any special or very specific commands. Mainly the queries and writes/updates of objects. Nothing very fancy. If you have very specific requirements of Realm than I suggest look into those and see if there are any special changes to how they are managed.
Now to the steps:
Remove the frameworks from the "Embedded Binaries" section by clicking the "-":
General Tab - Embedded Binaries
Remove the frameworks from the project itself by right-clicking on them and select "Delete"
Navigator - Framework Files
Now just go and do the steps for installing the frameworks as found in the documentation "realm.io/docs/swift/latest/#installation-swift-22".
I understand this question is rather old, but looking through the SO I dint find a definite answer to this.
Hope this helped!
I wish this is a stupid duplicate of an already answered question.
I have a asp.net website that depends on some other projects (dlls copied to bin). Now, what I want is every time any of those projects are updated, I get latest dlls in my website/bin. I DO NOT want my CI server to check-in updated dlls.
I already have a private NuGet feed for my project, and just want it to serve the latest dlls after each successful CI build. Now, my questions are
Is there a way to directly serve the dlls, without creating nupkg? And probably pick them from build output folder? (for some reasons, it's not that convenient to create package as a post build task for all the dlls hundred times a day) If that is possible, awesome!
If not, can we avoid increasing version number of dlls each time, still make nuget update to the new dlls? Something like update based on latest publish date or something? (there is huge bunch of dlls, and lot of dependencies)
Is there a way to take latest dlls without building the solution? Yeah, I can do a nuget update command, but is there any other way?
Someone suggested mirroring my current code base and using something like MyGet or ProGet. For several reasons, that is not feasible at the moment.
Triggering a Visual Studio build after any NuGet dependencies is probably not quite what you really need - that's a job for CI. However, you can set the version ranges in your packages.config file to make VS (via nuget) pull newer NuGet packages when available.
To answer your specific points:
Why would you want to server 'random' loose DLLs whose origin you cannot be certain of? NuGet provides a mechanism to track the origin of code on which your own code depends, which makes tracking down bugs easier :) If you rely on NuGet packages containing DLLs which change 'hundreds of times a day' then you should likely just build those DLLs directly with your application.
See #1 - if you are re-building NuGet packages very often, then you likely have your package boundaries wrong. Consider how truly independent your packages are, and see if it would makes sense to bring some of the DLLs together, or even separate out (fork) code which is shared between multiple separate applications. If you create a new version of a NuGet package, then you should increase the version number - that's a fundamental premise of semantic versioning, and you'll get into a mess if you do not follow this pattern.
To bring down the latest NuGet dependencies, nuget update is your friend :)
Using MyGet or ProGet might be part of a solution, but it's not directly related to the patterns you mention above.
I am using Qt in order to build a cross platform GUI app (Windows and Mac). I want to be able to update the app efficiently and automatically whenever there is a new patch available.
I saw this post which got me to take a look at WyBuild. It looks great and probably what I may end up using for the Windows version but what about Mac? What are some alternatives available to me?
I've just started developing a Qt-based autoupdater called Fervor for my own needs. You can try it out, contributions are more than welcome too.
For Mac the best choice is Sparkle used by WebKit, Adium, Cyberduck and more. Its only for Mac but I guess native look matters on Mac a lot.
Not familiar with WyBuild so cannot comment. Sparkle is a fine choice but the poster preferred a single app for both platforms. BitRock InstallBuilder contains an autoupdater written in Qt that can be used independently (disclaimer, I am the original BitRock developer). It is a commercial app, but we have free licenses for open source projects.
There is Updatenode which seems to provide a real Qt cross-platform solution.
It comes with a prebuilt client for Windows, Mac and Linux. The online service lets you manage updates very easy and are able to see good charts of your application usage.
And here another one of the possibilities:
Using the Qt Installer Framework: It provides installers for Windows/Linux/Mac with an build-in updater. If you need an example - The MaintenanceTool of your Qt-Installation uses the framework.
To get an auto-updater from it, all you need to do is:
Create an online installer (Just check the documentation, it's not that hard)
Use the maintenancetool in your application to check for updates.
This cane be done using my QtAutoUpdater. Go there for more information about the whole process
If new updates are available, the maintenancetool can be started in updater mode to install the update
Update the online repository - and your update is out.
Advantages:
Installer and updater in 1 tool - this means less work for you
Easy to use (with or without the QtAutoUpdater library)
Cross-Platform for all desktop platforms supported by Qt
The installer itself is a Qt original
Disadvantages:
No "native" installers (i.e. no .msi on windows or .deb on ubuntu)
Must be used together - if you want to use the update feature, you have to use the framework as installer
This may be obvious, but for Linux you can use the built in package manager. For example, apt-get, yum, pacman, or what have you.
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.
I'm trying to make a setup program for an ASP.NET web site. I need to make sure the target machine has sqlxml installed.
I must verify the target machine has the software installed, and if not, launch a .msi file either before or after the main installation.
I'm a complete newbie with setup projects, so maybe this is obvious, but after several hours browsing the web I haven't found a satisfactory solution. I've been reading about WiX, etc. but I'm looking (if possible) for a simple solution.
Thank you both!
I understand an installer can't run another one. I was thinking in a functionality similar to Prerequisites (in project properties). There I can check a component and it will be automatically installed if it isn't. I don't need to do anything else. But, the most important thing for me is that the installation won't run if it's not needed.
I also tried the .msm solution, but I couldn't find any. Maybe I can make one myself? I haven't tried it yet though.
Unfortunately, you can't run one installer from another, since only one can be running at a time. You need to chain them together and run one after the other. Google "msi chaining". This is often the reason why products like Visual Studio use an external setup.exe which then runs the installers one after the other.
Looks like you need to 'chain' the installs http://objectmix.com/xml-soap/84668-installing-sqlxml-net-app.html
You can get the redist here http://www.microsoft.com/downloads/details.aspx?FamilyID=51D4A154-8E23-47D2-A033-764259CFB53B&displaylang=en
CAn you add this as a pre-req for your install?
What are you using to build the create the install?
Edit:
I had a look to see how you can check of the SQLXML is installed and come across this:
http://www.tech-archive.net/Archive/SQL-Server/microsoft.public.sqlserver.xml/2005-04/msg00110.html
The system I am on just now has the following key HKEY_CLASSES_ROOT \ SQLXMLX (note the X at the end), so you might need to do a bit more investigation in to what the actual key is.
I'm not familer with Visual Studio install authoring but if you can add an entry to the AppSearch and RegLocator tables you should be able to check for the existance of the registry key when the install starts. See here
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
The Reglocator table gives you the option to set a property with a value from the registry if found. You can then use this in the condition on a custom action.
A lot to put together, but I hope it move you in the right direction.
Brent's answer is correct. I would just add that, sometimes, you can find a "merge module" for the bits you depend on. That's a .msm file. You can certainly include 1 or more of those in your .msi file. I have no idea whether a merge module is available for SQLXML. Sorry.