I'm having a project with Wix 3.0 and another project with Wix 3.8 versions.
I can't use both versions same time for these projects. Each time i've to unintall/install wix build based on projects.
How to use without uninstall old wix build for the projects.
Anyone please suggest me what has to do to achieve?
The technique described here: http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html can be used on development systems to allow building projects with different versions of the WiX Toolset ...
The problem is in maintaining projects which require different versions, especially if you have multiple developers working on these projects.
Hope this helps!
Related
The question is at the end - let me start by posing the context:
One of the problem we are facing at work when using Visual Studio is to make sure that everybody on the team is using the same version of the SDKs.
A typical problem would be to have somebody use a different Direct X SDK version resulting in a different behavior of the code, or somebody upgrading to a more recent Platform/Windows SDK in order to use some new API and having the code fail on other's programmers machines if they still use the previous version.
A way we used to solve the issue for other middleware has been to put the whole set of libraries, include files, tool chains, etc... in our source control system, and have our projects to use these so nobody has to install anything.
We also managed to do that with earlier version of the Direct X SDK, but we always ran into issues with the Windows/Platform SDK due to the close links between the SDK and the toolchain.
Since we now have to support both VS2010 and VS2012, and have to support from Windows XP to Windows 8 targets, we have to support v100, v110 and v110_xp toolsets.
This means that we need all the associated compilers and the corresponding SDKs, both on our developer machines and build systems: This is getting ridiculously costly to maintain, specially considering that random windows updates and .net framework releases routinely tend to break msbuild.
So the question is:
Is it possible to have Visual Studio to use non installed toolsets and SDK and instead having it use whatever is available in some folder out of the normal VS installation locations?
Bonus question: If it is doable, is it possible to do that without having to change any locally installed configuration file on the machine - ie: Have all that in the solution/project or property sheets - so if we change the structure on the source control system we don't have to update every single machine?
Thanks :)
This sounds too complicated, given how complex some of these tool installations are. I would solve this problem by investing in some PowerShell scripts that look at the installed tools and tool paths and "police" the installations. It would be relatively easy to check for installed versions of everything, including patches and updates. You can run those nightly, or as part of a build. Also, you can compare aspects of different installations, such as the tool versions installed on a developer box with your build server.
This would give you 90% of the value for 10% of the pain.
The problems you describe are not solved with your approach. What you actually need is a build server and a definition of done including using binaries built with the build server. You also need a test suite as part of the build definition with some invariants related to the build environment used.
I have an application which require .net 2 and .net 4 framework with adobe reader , i want to install them before software installation, how i am supposed to do this? Kindly please guide me towards right direction.
This is usually done by adding the packages you need as prerequisites for the main installer. Most commercial setup tools support prerequisites one way or another. Here is a list which can get you started:
http://en.wikipedia.org/wiki/List_of_installation_software
Pick a tool and try using it to create your installer and add prerequisites for it. I recommend Advanced Installer or InstallShield. If you want a free solution, you can try WiX.
What you need is basically a suite installation. The link I included shows how to do this with Advanced Installer (Disclaimer: I work on this tool). This is a commercial tool, but it saves you from learning to code Wix/NSIS projects, as it is completely GUI driven, thus you can built your installers without writing any code.
With NSIS as your installer, you can refer to the following pages for help with detecting and installing .NET:
How to ensure a required version of .NET Framework is installed
How to automatically download and install a particular version of .NET if it is not already installed
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.
I'm looking for Qt packager for my Qt application targeted for windows platform.
I need it to create a nice installer to deploy and distribute my product on windows PC.
Which is best and recommended FREE packager?
For packaging I use the WIX (Windows Installer XML) toolset.
There are several advantages to using WIX:
Free and open-source
Creates MSI files, which allows your application to be easily deployed across large networks and correctly uninstalls (also very important)
Supported and developed by Microsoft, it is used by several other Microsoft teams internally, e.g the Visual Studio 11 Developer Preview installer features some of the latest WIX features
XML configuration allows reuse of components of installers (sets of files, feature sets)
Several types of user interface, new wizard pages can be created
Integrates into Visual Studio
Integrates into MSBuild - can allow consistent packaging to ensure you don't ship debug versions
I have used WIX for installers at work and for my own projects at home.
It isn't as simple as other solutions to get started, but once you've created a simple package, you'll find it easy to add new features.
NSIS is the way to go in my opinion. Straight forward scripting, compatible with all Microsoft Operating Systems and with support for User Levels.
Plus it has a huge active forum for any specific help you may need. I use the HMNSIS editor to write the scripts and have not come across anything it hasn't been able to do yet!
Qt has nothing that can help you, but the free Windows installer package creator is without a doubt NSIS
Inno Setup is a another good, free, light-weight installer system.
There is the Qt Installer Framework. That is a link to the manual for it. It is multi-platform. With it, you write XML files in a directory structure for delivery of components in the directories, called packages. It has scripting. You then compile it into a setup for your target platform.
Correct me if I'm wrong, but I was under the impression that they did not make it available to users of the Community edition until recent versions. When the earlier replies were written, it may well have been commercial version only.
Alas, nothing seems to warn you that you have to collect up components, nor tell you what they are, or even talk about the process; except that the 3rd. party, but free (Windows only), Dependency Walker can tell you what dynamic libraries are being used. I don't find it a necessity, but it can be helpful. (Tip: On Windows anyway, be sure to put "qwindows.dll" in a "platforms" directory with the exe. Tip #2: Make sure the Qt DLL's or static libraries are ones compiled for your compiler.)
I currently have Visual Studio v2003, v2005, v2008 installed on my system. Things work fine...no issues.
I now have to install Visual Studio 2010 on my system and just wanted to know if anyone has a setup like mine or knows if there are any potential issues with so many versions existing on a system.
Really don't have a choice to remove older versions as we have a lot of legacy products written in these old versions and we are not upgrading them to new versions, only doing bug fixes on them.
Any ideas?
Thanks!
VS2010 supports targeting on multiple versions of .NET Framework (i.e. 2.0 or later), which mean it is designed to support the projects that were built with VS2005/VS2008 so-called backward-compatibility.
So I think no conflict here between these versions,
I've found a nice Myths and facts about VS 2005/2008/2010, check out this link here: http://msdn.microsoft.com/en-gb/ee679805.aspx
It should work.
I have vs2003, vs2008 and vs2010 installed and I see no issue (but vs2010 is not yet used for production code).
M.
All these versions of Visual Studio are independent.
You should have no problem (other than lack of disk space!) installing VS2010 as well.
Just make sure you install the service pack as well.
They cohabitate fine, I have a similar setup myself.
You should at least push for migrating away from 2003 and 2005 though, they use some pretty old technology, and pretty much everyone these days has .net 3.5 on their systems.
If you are able to use VS 2010 I would highly recommend you do for all new projects - even if you have to target an earlier version of .NET framework.
Keep the old versions of VS installed only for maintenance of projects that cannot be migrated to VS 2010 version.
By the way, the migration to VS 2010 is often very trivial and well worth an hour or two of effort!