Jörg Bornemann

Qt VS Add-in 1.1.9 released

Published Wednesday March 30th, 2011
35 Comments on Qt VS Add-in 1.1.9 released
Posted in Qt, Windows

Today we’ve released version 1.1.9 of the Qt Visual Studio Add-in.

The following fixes are included:

  • Fix a regression when importing .pro files that was introduced in 1.1.8.
  • Make the add-in work with Intel VTune projects. (QTVSADDINBUG-65)
  • Check for compatibility with VS version when adding new Qt version. This will hopefully stop people from trying to use a MinGW Qt build with Visual Studio. 😉 (QTVSADDINBUG-58)
  • Added possiblity to specifiy lupdate/lrelease options. (QTVSADDINBUG-48)

You can get it here: http://qt.nokia.com/downloads/visual-studio-add-in

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Qt, Windows


David says:

Thanks for your effort 🙂
I’m a big fan of VS and .NET, but I think that if you spend your time creating an addin for VS, you should do it as good as Qt Creator is or focus your resource and time to Qt itself. Currently the VS addin is not very practical. I understand you charge for a full VS integration but what LGPL users should do?

qplace says:

Thank you for the release of the wonderful product. Contrary to what David wrote in his (unfortunate) first comment to this release, many people, myself included, are using Qt Vs Add on on a daily basis. I remember times when it was commercial product and it was quite painful to work with Qt and VS using .pro files.

Thank you again and please keep up making it better. And yes, I don’t care much for QtCreator until I move to Linux.

Martin Ribelotta says:

Many thanks!!!!

OT: When I saw the headline, add unconsciously “Vs Predator”

Jim says:

@Martin Ribelotta ha ha ha. that was my first thought when I saw the title.

Jörg Jörg says:

@David: no, we don’t offer a full VS integration anymore. The last release was for Qt 4.4.2. The Qt VS Add-in is open source and we’re accepting merge requests. So if you want to fix / enhance something, feel free to do so. You can also contribute by reporting bugs. That’s what LGPL users should do. 😛

@qplace: Many thanks!

@Martin: The Qt4 song video is pretty old now. Maybe its time for… a movie! 😀

David says:

Yes, right :))))

Martin Ribelotta says:

@Jörg +1 to Troll Movie 😀

Markus Fleck-Graffe says:

Please note that you may not distribute any binaries created with VS under the LGPL license. Let me quote the LGPL (v2.1):

“For an executable, the required form of the ‘work that uses the Library’ must include any data and utility programs needed for reproducing the executable from it.”

While an exception is given for “anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs”, VS is *not* “normally distributed as a major component” of Microsoft Windows at all, so this exception does not apply here. Neither would you be allowed to distributed any version of Visual Studio along with your application, as far as I know, so you really do have no way to satisfy this condition.

I am just trying to make it clear why Qt comes with MinGW by default. You *can* use VS with the LGPL license, but then you must either buy a commercial Qt license if you want to distribute any binary that is linked to Qt, or you must be doing internal-use-only development, i.e. refrain from distributing the resulting binary outside of your organization at all.

Thomas says:

Since the Express Edition is more or less “free”, as is the compiler in the SDK, doesn’t that change things?

Markus Fleck-Graffe says:

No, Microsoft’s EULA (“End-User License Agreement”) explicitly forbids redistribution or transferral of “Visual Studio Express Edition” to third parties (i.e. the receivers of your Qt-based binary).

(Apart from that, the EULA even explicitly forbids distribution of the resulting binaries to run under non-Microsoft API emulators, such as WINE. This may be mostly irrelevant for most people, but serves to demonstrate once again the difference between “free speech” and “free beer”.)

Thomas says:

Still, I don’t quite see the point. Just because Qt is LGPL doesn’t mean that my product is.

To quote Wikipedia (http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License):

“A standalone executable that dynamically links to a library is generally accepted as not being a derivative work (in LGPL). It would be considered a “work that uses the library” and paragraph 5 of the LGPL applies.

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. “

Tim says:

Thanks for releasing this great add-in. It makes using QT with VS much easier.
I received an error “this Qt version uses an unsupported makefile generator (used: MSBUILD supported msvc.net)” which doesn’t occur with v1.1.7. This is with MS VS 2010 and QT 4.7.2. I haven’t downloaded the source to find out why and I know MS VS 2010 is a tier 2 platform but thought I’d ask anyway…

Thomas says:

Sorry, I forgot the most important part:

“Essentially, if it is a “work that uses the library”, then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use “a suitable shared library mechanism for linking””

so to me, after reading it several times, and section 6 b) from http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html, it sounds as if this is not necessary in the case of shared libraries.

Markus Fleck-Graffe says:

Yes, but shared libraries created by VS and those created by MinGW are incompatible; that is, as far as I know, one cannot link a binary created using VS with a version of Qt made with MinGW. (Because of incompatibilities involving C++ name mangling and compiler-specific runtime code.)

But, due to several restrictions regarding the redistribution of any version of Visual Studio, you cannot “include any data and utility programs [such as Visual Studio] needed for reproducing the [VS-built] executable”, either. Visual Studio doesn’t normally come bundled with Windows, so the “major components […] of the operating system” exception does not apply, either.

It a nutshell, you are not allowed to distribute a VS-compiled executable that uses an LGPL-licensed C++ library, even if the latter has been compiled (by VS!!!) as a shared library.

Thomas says:

I’m no lawyer, but I’m still not convinced that you are right (apologies for hijacking this thread), but as I understand it the whole point of “any data and utility programs needed for reproducing the executable from it” and dynamic libraries is that you don’t need to reproduce the executable. I think this intended to cover the case of static libraries where you need to relink the application to get the new code into the apllication. Everything is fine as long as the application works with the users dll that is “interface-compatible with the version that the work was made with”. I don’t see where I am forced to provide the tools to enable him to create an interface-compatible version from the source.

Jörg Jörg says:

OK guys, let me join the spare time lawyer discussion.

DISCLAIMER: I am not a lawyer. This is not an official statement. Oh and this is not an April’s fool joke.

@Markus: Qt is released under the LGPL 2.1 with the Nokia Qt LGPL
Exception [1]. Thus a program linking dynamically against Qt counts as “work that
uses the Library” and “therefore falls outside the scope of this License” (LGPL).

It is a myth that you cannot distribute binaries using LGPL Qt built
with Visual Studio. Your arguments can also be applied to MacOS X and Xcode.
This would leave LGPL Qt as gcc only toolkit.
Well, that’s just not the case.

Further, we *are* offering VS 2008 binaries [2].
The reason that the Qt SDK comes with MinGW and a Qt built with MinGW is
simply that the SDK is supposed “create a complete offering” which contains a toolchain.
And for obvious reasons we cannot redistribute the MSVC toolchain (nor Xcode).

I see no reason to use MinGW on Windows unless you need a GNUish environment to port unixoid software, e.g. git.
If you’re writing Qt programs use the toolchain Microsoft provides. Period.

There is no problem with VS and LGPL Qt.
If you’re using the MSVC toolchain to create Qt programs you might not get the 72 geek girls after you’ve erased every trace of proprietary software from your machine. But you’re on Windows anyways.


[1] http://doc.qt.nokia.com/4.7/lgpl.html#nokia-qt-lgpl-exception-version-1-0
[2] http://qt.nokia.com/downloads/windows-cpp-vs2008

danny says:

“I see no reason to use MinGW on Windows unless you need a GNUish environment to port unixoid software”

Two words. Standards Compliance.

RazrWire says:

1.1.3 was the last add-in that would produce executables with proper program icons… I have tried 1.1.4 through 1.1.8 and all manage to mess this up. Is there a proper bug report on this topic? I can’t imagine that we are the only programmers who care if our executable has a custom icon on it.

Markus Fleck-Graffe says:

The problem is not about a “work that uses the Library”, i.e. your own VS-compiled EXE, but about linking to VS-compiled Qt libraries. The LGPL says that you are obliged to provide the user of your EXE with *all* the extra tools required to build a modified (or even an identical) copy of the required (LGPL’ed) Qt DLL, which must be able to work with your original (VS-compiled) EXE.

To still comply with the LGPL, you might (hypothetically) have to buy VS for every receiver of your software – which would be absurd, because it is much too expensive. You cannot just distribute VS Express along with your application either, because Microsoft disallows its redistribution.

Imagine yourself as the receiver/buyer of your application. According to the LGPL, users are allowed (and encouraged) to patch and replace the Qt DLLs that are used by the application. Imagine that you want to patch Qt, for instance, to add handling of a recently-defined new Unicode character that you need; imagine someone else has already posted a corresponding patch to the Qt source code on the Internet that you could use. However, you cannot build a modified version of the Qt DLLs, because as an ordinary user, you are missing the whole compiler/linker toolchain. Now, according to the LGPL, you can claim to receive “any data and utility programs needed for reproducing the executable”, except for those which are already “normally distributed” with “the operating system on which the executable runs” (which is not the case for Visual Studio). Therefore, as a user, you can ask your distributor to provide VS (or at least some kind of “build service”) so that you, yourself, can patch in support for that Unicode character to the Qt library that the application links to. According to the LGPL, you are not obliged to buy a copy of VS yourself to be able to exercise your right to replace the linked-to Qt DLL.

The initial motivation for starting the GNU project was a deficient printer driver that couldn’t be fixed due to a non-disclosure agreement. Apparently Richard Stallman wanted to make sure that even in the case of the “lesser” general public license (i.e. LGPL), every user still had the right and practical possibility to patch bugs in an application, even a (mostly) proprietary one, by at least being enabled to patch the LGPL’ed parts of it. This is why the LGPL demands that Reverse Engineering must be allowed for the *whole* application (not just the LGPL’ed parts of it), and that all the build tools and scripts must be available to the user without additional cost, and that the distributor must make this sure.

Joe Jack says:

“Two words. Standards Compliance.”

So then you’d be using ICC or LLVM/Clang then, no? G++ lacks a number of C++ features and has plenty of its own non-standard extensions.

Adrian says:

As Tim mentioned, I also received an error “this Qt version uses an unsupported makefile generator (used: MSBUILD supported msvc.net)”. What should be done? A little help?

Adrian says:

I’ve spent all day trying all sorts of combinations to get this kicking and nothing worked. Is anybody reading this?

Thomas says:

Maybe I’m blind or unable to understand the true meaning of what is written, but I still don’t see it and fail to see where it read so in the license. As i read it there are three parts involved. The LGPL uses this wording: “linking a “work that uses the Library” with the Library creates an executable that is a derivative of the Library”.

As I see it the “work that uses the library” is the physical .exe file on the drive with the unresolved links to the library. The LGPL’d libraries are the QT dlls on which it is dependent. The “data and utility programs needed for reproducing the executable from it” is the OS that binds the stuff together in memory before execution. The user has all of those tools. Nothing missing. LGPL terms honored. The users has the “wherewithal to run that program using a modified version of the Library.”

I just don’t see where the LGPL makes it my job to provide the tool chain needed to build a modified version of the Library.

Adrian says:

Hey, your Add-In Does NOT work! Do something!

Thomas says:

@Adrian I have no idea how you expect anyone to help you if you just scream “help”. Give some detail. OS (XP, Vista, Windows 7), OS Subsystem x32 or x64, what version of Visual Studio 2003, 2005, 2008, 2010, and what you are doing or trying to do, (what sort of project is it – Qt Application, Qt Designer plugin,… ) or whether you are importing a .pro file.

Markus Fleck-Graffe says:

Of course “data and utility programs needed for reproducing the executable from it” (at build time) does not refer the OS, and it has very little to do with “binding the stuff together in memory before execution” (at runtime).

The OS itself cannot create (i.e. “reproduce”) executables. You need a compiler, linker, etc. for that, and you will have to provide these (or access to them) with your application, unless these tools come with the target OS (which is not the case for Windows).

Maybe the confusion comes from the term “reproduce”. In the context of the LGPL clause, it means “re-create” or “re-build”, rather than just “copy” or “run”.

Adrian says:

@Thomas: Visual Studio 2010, Windows 7 x64, Qt 4.7.2. I can’t start a project (any sort of project) because I can’t use Qt in Visual Studio. I downloaded the source code, changed the environment variables, ran multiple configure commands combinations (which all ended successfully), always followed by an nmake command (which also ended successfully). Afterwards, I installed the Qt Visual Studio Add-in 1.1.9. When in VS I went to Qt->Qt Options->Qt Versions and I added the current Qt Directory (4.7.2) it gave me this error:

This Qt version uses an unsupported makefile generator (used: MSBUILD, supported MSVC.NET)

Thomas says:

Why would the user need to be able to recreate the executable when this is not required to run a modified version of the Library? That is the case for static linking, not dynamic linking. If your interpretation is correct, why does the LGPL differentiate between static and dynamic linking and defines what it understands as “a suitable shared library mechanism”?

Adrian says:

Sorry for the anger shown above but I had accumulated tons of frustrations and had to export them somewhere. Installing Vs Add-In 1.1.8 solved the issue. Sorry again. 🙂

Immanuel says:

Hey all,

I’m having similar problems like Adrian. In the need of using Qt as 64 bit version with Visual Studio 2010 Ultimate I had to build it myself. which worked quite well. unfortunately the VS Addin responded to this build with the same error that Adrian had: unsupported makefile generator. This is specified in the platform file in the mkspecs folder and the generator changed from msvc.net (2008) to msbuild (2010).
I thought that this can be solved by building the Addin myself, which did not help at all, it even did not let me use the binary library from Qt, as the versions were different (1500 (2008) vs 1600 (2010)). Well then I tried changing the generator, but in the meantime I wanted to create a new qt project to test, but something got broken and the project wizard, caused an exception when I clicked “finish” and jumped back to the window were one can choose from the different project types. the exception is not visible in normal runtime, but debugging this visual studio session made it visible: “Eine Ausnahme (erste Chance) des Typs “System.Runtime.InteropServices.COMException” ist in Microsoft.VisualStudio.Dialogs.dll aufgetreten” (the german error just tells, that an exception occurred). While getting very frustrated, as by now two different things did not work, I continued my search and looked into the script in “C:Program Files (x86)NokiaQt4VSAddinwizardsQt4GuiProjectscripts1033” and commented most of it out and then found out that as son as “QtEngine = new ActiveXObject(“Nokia.QtProjectEngine100″)” is called, the exception in visual studio occurs.
Then a got back to this blog post, and found Adrians comments and tried to install 1.1.8 to, but unfortunately the wizard continued not working. maybe this solved the makefile generator thing, but I deleted my x64 build of qt in the meantime to just get the x86 build back working. hopefully somebody knows how to fix it, as I don’t know what to do anymore.

Thomas says:

Sorry, can’t be of much help here as it appears to be workling on my machine. Still there are a lot of compatibility issues with the Qt dll’s, something that should be taken care of. There are not only the incompatibilities between gcc / cl versions, but also between the version compiled by different version of the the visual c++ compiler. These depend on different microsoft runtimes which may or may not be present on the system. Also the Qt dll’s are not always backwards compatible as the api sometimes gets enlarged and yet all them are just called Qtxxx4.dll. This can lead to compatibility issues anytime an installation adds another Qt dll 🙁

That’s why one must kind of recommend either static linkage or building a custom qt dll.

Daniel says:

@markus may I point out that the Windows SDK provided by Microsoft is download-able for nearly every version of Windows released this century and that it provides all the took chain tools necessary to compile a VS project or solution file. While it does not provide the “nice IDE” that is VS it does allow compilation of the required DLL or Statically linked project, from either a sln or a vcproj file. Because the SDK is not a sold product by MS the version that you would have to download to build your application can be distributed with any release of the LGPL software as required by the LGPL (as you are interpreting it).

qplace says:

@Jörg: Is there a place on qt.nokia website where I can submit a potential problem with new Qt AddIn release? I am not sure that it qualifies as a “bug”, therefore I don’t know if I should use a bug tracking site. This is a behavior that I did not see with prior versions of QtAddIn/VStudio and I’d like the developer(s) of Qt AddIn to be aware of it.

Immanuel says:

Hey, somehow I managed to get the wizard back working. To build the addin succesfully I guess a few more environment variables have to be set, which can be found in the qtvars.bat in a prebuild binary version of qt (but have to be adjusted to match ones qt folder). Doing so and using the collectInstallerFiles.bat I was able to create a working version (the collectInstallerFiles I guess is unneccessary, but I puts all needed files in one clean place).
Now back to my first problem, the unsupported makefile generator. for a reason I don’t understand the addin allowed me to use my self build x86-build, and it works just fine. then I tried to build the x64-version again and wanted to add it with the addin and here the error comes again. that’s very strange. well I read that the generator check was implemented to prevent one from using a mingw build of qt with visual studio, therefore the addin checks for “msvc.net”, but the visual studio 2010 mkspecs are setting the “msbuild” as a generator. does the addin require really the msvc.net and it can’t work with the msbuild or is this just a little bug here and it should check for both generators? and like qplace asked, such a place would be really great, as I normally don’t like to flood blogpost comments with such things 🙂

Jörg Jörg says:

For the “adding a Qt version in VS 2010 doesn’t work” problem someone already created a bug report:
You can click on “Watch this issue” to be automatically notified about the progress of this issue.

“1.1.3 was the last add-in that would produce executables with proper program icons… I have tried 1.1.4 through 1.1.8 and all manage to mess this up.”
It seems that you are having this problem for quite some time. Please file a bug report at http://bugreports.qt.nokia.com/ so we can fix it.
The add-in doesn’t do much about .exe icons apart from adding them in the “New Application” wizard.
Here’s how program icons work with MSVC: http://en.wikibooks.org/wiki/Windows_Programming/Resource_Script_Reference

If in doubt, just use the normal bug tracker. That’s the place we’re constantly tracking and where we will comment on issues.

Commenting closed.

Get started today with Qt Download now