The problem
I have a Qt IFW installer with an online repository, from which users fetch data to install and update the software.
My installer has a "root script" defined in config.xml:
<Installer>
<!-- ... -->
<ControlScript>controllerscript.qs</ControlScript>
</Installer>
Now I want to change the content of controllerscript.qs and deploy it on the online repository.
when a new user installs the software for the first time, it works as expected
when a user updates its software from a previous version using MaintenanceTool.exe, it does not get the update
Possible solution
I realized that when you create the installer, it generates a file named MaintenanceTool.dat which seems to contain controllerscript.qs (+ other things). I managed to manually copy that file and push it to the online repository (inside a package). That way, the maintenance tool is able to see the package update, and correctly gets the new MaintenanceTool.dat. After that, the maintenance tool is indeed using the new code from controllerscript.qs.
Question
Is there another (cleaner) way to achieve that?
If not, is it really safe to provide a manual update to MaintenanceTool.dat? That file contains many other things, so is there a risk to interfere with the rest?
Thanks,
Related
I'm trying to write my first Qt installer and having trouble. In my installer, in one of the packages, I need to run an .exe file at the end of the installation and add an environment variable as well.
I think the way to do it is with the script option in the package.xml file but I don't know how to write that script, I cannot find a step by step explanation of how to do it anywhere.
Can someone help?
I have been recently suffering the same fate as yourself but have managed, for the most part, to achieve what you are trying to do from the Qt installer framework examples and documentation found here http://qt-project.org/doc/qtinstallerframework-1.5/index.html and http://doc.qt.io/qtinstallerframework/qtifwexamples.html.
The information provided on these pages is a little ambiguous but with a little experimentation you should be able to create the install script that you require.
The package.xml file you would like to implement the install script requires that you add a
<Script>installscript.qs</Script>
tag and that the installscript.qs its self should be located in the meta folder of that package. The installscript.qs will then contain, among a few other things, a
component.addOperation("Execute".....)
command which will execute your required .exe. The same process for the environment variable could be implemented using the execute operation to run a batch file which creates the variable on the users system.
I have been trying over the last few weeks to implement the custom operations detailed in the qt installer framework documentation but have so far been unsuccessful so if you make any progress in this area feel free to pass the information on ;)
In the MiniProfiler.MVC3 NuGet package, it creates a file in App_Start that is used to control MiniProfiler settings (the SqlFormatter to use, modifications to the ViewEngines, when to start MiniProfiler, etc.).
There are a lot of TODO comments in this file talking about how to change the code to perform how you want. This is great, but when the NuGet package is updated, it will see that I've changed the file and not pull down the updated version. The problem here is that I lose any updates to that file, and depending on what else updated in the package, making it unusable (for example, when upgrading MiniProfiler.MVC3 from version 1.9 to version 2.0.1 after modifying MiniProfiler.cs in App_Start, the project will no longer build because of needed changes to that file in the 2.0.1 version).
What is the best way to handle this? Should I create my own file in App_Start and not modify the one in the NuGet package, ensuring that I will always get the full update when upgrading to the latest version of the NuGet package?
You could backup the file in App_Start, update it, then merge the files manually, or using a merge tool. You'd probably end up doing this anyways if you're using source control.
Quick-and-dirty: create the file you want. Then copy over/merge every time you upgrade with nugget. Or with every compile. The added build time is negligible.
Slightly better: use the precompile event in visual studio and compare the files. If they differ - either copy over or tell the user. I can't figure out a way to show a message box, or similar, on the top of my head but one could always create a new file with a compilation error and some text nearby "discrepancy in the xxx file".
try using mercurial queues. You can get your code to the point you want (excluding the file you refer to), and then commit. Make changes to your file, and push it to a queue. Make sure to exclude it from any future updates (manually), and then when you want to update your package, pop it off your code base. This will make it look like it used to, and run the nuget update. Then you can push the queue back to the code, and your changes will re-applied. It might take a bit of fiddling, but worth a look.
For reference:
https://www.mercurial-scm.org/wiki/MqExtension
https://www.mercurial-scm.org/wiki/MqTutorial
https://developer.mozilla.org/en/Mercurial_Queues
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
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.