I have created an installer with Windows Installer XML 3.5 from within the Visual Studio 2010. The installer itself works pretty well but now I would like to change it's default language from english (1033) to german (1031). Therefore I changed the language attribute within the product tag to "1031" which should do the magic as far as I know but nothing happens. The language is still english.
<Product Id="MyProductId" Name="NameOfMyApp" Language="1031" Version="MyVersionNumber" Manufacturer="MyCompany" UpgradeCode="MyUpgradeCode">
What am I missing here?
You can also do it in Visual Studio: Project - Properties - Build - Cultures to build.
You need to specify the language (culture) on the command line when building as described here (or in the project properties when you are using Votive):
WiX Tutorial - Do you speak English?
candle.exe SampleWixUI.wxs
light.exe -ext WixUIExtension -cultures:de-de SampleWixUI.wixobj
Related
I normally work in C# but today need to debug some custom code in VB.net from an ssrs report. I want to create a vb.net project to use as a test harness..however my only Installed Templates are for C#. After googling all I can find is a re-install or install the express edition. That doesn't seem to make sense to me as Telerik adds their product as a new language and it shows up fine.
So I would like to have C# & VB.NET under the New Project >> Installed Templates section and thought it would simply mean checking a box in options or copying some files from the install cd to a directory(ies)...???
Express editions of Visual Studio have limited functionality.
If you wish to work with both C# and VB.NET using the Express editions, you need to download and install both versions.
The installer includes the toolchain - the compiler and such, so just getting a project template will not help. Additionally, the IDE for each will only be able to open and work with specific project types.
With other editions, you can re-run the installer and select VB.NET as an option. If not originally selected, the compiler and templates wouldn't have been installed.
I created a WIX project in Visual Studio 2010 over a year ago. It creates an MSI file and a bootstrapper setup.exe. Actually, it creates that pair of files for two languages - English and French. I am just now integrating this project into our TFS CI builds. I'm having trouble getting the CI build to generate the bootstrapper setup.exe files.
We've recently upgraded Wix on all our build servers to Wix 3.6 RC. So, I thought I'd give Burn a try instead of using the old style of bootstrapper. I added a new Bootstrapper project to my solution. The bootstrapper project includes a simple bundle.wxs that just loads the MSI generated by my old MSI project. However, when I try to build I get the following error:
error LGHT0103: The system cannot find the file
'C:\Tf\Advantage\Dev\Solution\Configuration\LaunchPad.Wix\bin\Release\fr-fr\LaunchPad.msi;C:\Tf\Advantage\Dev\Solution\Configuration\LaunchPad.Wix\bin\Release\en-us\LaunchPad.msi'.
My package reference in the bundle looks like this:
<MsiPackage Id="MyApplication" SourceFile="$(var.LaunchPad.Wix.TargetPath)" />
LaunchPad.Wix is the name of the Wix MSI project. If I change the LaunchPad.Wix project to build only one language then it works fine. It looks to me like the bootstrapper project type just doesn't support building setup files for multiple languages. Is this true? Any suggestions for a workaround?
Edit
Upon further investigation, I wonder if bootstrapper projects even support localization. I tried setting my Wix MSI project to create only fr-fr. The setup.exe that my bootstrapper project created with English. When I edit the project properties for the bootstrapper project the "Cultures to build" field is locked down and blank. How would I build a non-english bootstrapper? Is this possible yet?
There are several things going on here:
If you use multiple Cultures, you can't use TargetPath in something outside MSBuild that expects a single filename. As you found, TargetPath is a list of the localized files that were built. However, you can use TargetPath if you qualify the .msi package's output language: <MsiPackage SourceFile="$(var.TestMsi.en-US.TargetPath)" Id="MsiEnUs" />
If you want to create one bootstrapper that can install either/both en-US and fr-FR, you'll need to list each .msi package separately in its own MsiPackage element.
If you want to create two bootstrappers, one en-US and one fr-FR, you'll need to invoke the bootstrapper .wixproj twice, once for each language. Bootstrappers don't support the Cultures "trick" -- it's problematic to produce two outputs from a single invocation of MSBuild (witness the TargetPath problem).
If you're using WixStandardBootstrapperApplication, it automatically tries to localize the UI based on the user UI language, falling back to the system UI language, and finally falling back to English. It looks for localized strings in directories named after the LCID, so you'd have payloads like this:
<Payload Name="1033\thm.wxl" SourceFile="..." />
<Payload Name="1036\thm.wxl" SourceFile="..." />
Unfortunately, WixStandardBootstrapperApplication strings are currently available only for en-US. That's why an fr-FR bootstrapper shows UI in English. You'd need to localize the WiX source file HyperlinkTheme.wxl or RtfTheme.wxl (depending on which theme you use). Both of these files are in src\ext\BalExtension\wixstdba\Resources.
good. it works as Bob Arnson said.
but you must pay attention to the name and the SourceFile of payload.
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<Payload Name="2052\thm.wxl" SourceFile="2052\thm.wxl" />
</BootstrapperApplicationRef>
if you change the name to another one. the bootstrapper will not be localized.
I've generated pseudo-localized versions of an app's resource files (for example Order Summary and Payment is localized as [[[[[Òŕd̂ër̊ S̀úm̂m̈år̀ý ân̈d̊ P̀áŷm̈e̊ǹt́]]]]]) so that we can test for localizability bugs ahead of getting actual translations.
I have named them using the qps-ploc resource identifier to match the existing pseudo-locale identifier, e.g. my pseudo-localized version of Details.resx is named Details.qps-ploc.resx.
However when I add these resx files to the project, Visual Studio ignores them. If I rename them using a "real" language code (such as Details.fr-FR.resx) then Visual Studio does create a subfolder named with this language code and builds the satellite assembly.
So it looks to me like Visual Studio rejects qps-ploc (without even a build warning). Am I missing something or can anyone suggest a way to get these qps-ploc resources built as part of my Visual Studio project?
The qps- locales work fine in my ASP.NET web application with .resx files (not compiled resource dll), however, I did find this MS article on enabling pseudo locales in the registry. Perhaps it will help.
Using Pseudo-Locales for Localization Testing
Additionally, you may wish to create custom locales, as given in this MS article:
How to: Create Custom Cultures
Best regards.
I am trying to go through the example at http://msdn.microsoft.com/en-us/library/aa719643(VS.71).aspx
Visual studio 2010 does not recognize System.Web.SessionState and various others.
I tried adding a .net reference to them but they do not exist on my system. I have .Net 4 installed.
Why would these examples use namespaces that are not recognized by visual studio?
alt text http://www.phantix-llc.com/system.web.sessionstate_missing.jpg
System.Web isn't shown because VS2010 defaults to using the .NET4 Client Profile which doesn't include it. (You can see the "Filtered for .NET Framework 4 Client Profile" text at the top of the Add Reference dialog.)
You need to change your project's properties so that it targets the full version of the framework, then you'll be able to select System.Web.
System.Web.SessionState (and the others shown unrecognized) are in System.Web.dll. Verify that reference exists.
How can I convert existing vcproj files to project files that the QT add-in to Visual Studio recognizes and treats as valid Qt projects?
Should I just bite the bullet and create new projects to replace the old ones, and then add existing code?
I am using QT 4.6 and VS 2008 with Qt Add-in 1.1.2.
Original vcproj files have NOT been generated with QMake.
Using Visual Studio 2010+ it is now possible to convert a project to a Qt Addin project, using the "Convert project to Qt Add-in project" feature of the Qt Addin.
The following steps are from the work around in bug QTVSADDINBUG-27. This was tested with Visual Studio 2010, but should work similarly with new versions:
Right click on your project in "Solution Explorer", click on "Unload Project"
Right click on your project in "Solution Explorer", click on "Edit .vcxproj"
Add line <Keyword>Qt4VSv1.0</Keyword> between the tags <PropertyGroup Label="Globals"> and </PropertyGroup>.
Right click on your project in "Solution Explorer", click on "Reload Project"
Right click on your project in "Solution Explorer", click on "Convert project to Qt Add-in project"
If you have header files in your project you are going to have to follow the instructions in this answer to trigger the generation of moc_* files in the "Generated Files" folder.
For editions of Visual Studio older than 2010 see this work around.
Here's the response from Nokia support engineer, name removed for privacy protection:
Hi,
Thanks for the suggestion. I have
passed it on to our developers who
will consider implementing it for a
future release. You can track it using
the following link:
https://bugreports.qt.io/browse/QTVSADDINBUG-27
Regards,
Support Engineer, Qt Development Frameworks, Nokia
>
Original question
We have quite a few legacy vcproj projects that we wish to add Qt to it.
Currently, we don't have an easy way to convert these legacy vcproj
files into a Qt-enabled vcproj.
What do I mean by Qt-enabled?
On a non-Qt-enabled vcproj, when I right click on the project name
under Solution Explorer, all options related to Qt are all grayed-out.
It would be really useful if Nokia adds this capability to VSTD Add-in.
Stackoverflow fellows, if you would like to see this feature implemented by Nokia, please help vote for it at the link above! =)
I use Qt VS Tools instead of Qt VS Add-in.
Instructions
In the .vcxproj file, make the following modifications:
Add <Keyword>Qt4VSv1.0</Keyword> into <Project><PropertyGroup Label="Globals"> (in accord with Benjamin's answer).
Add the following element into <Project> (the root element):
<ProjectExtensions>
<VisualStudio>
<UserProperties MocDir=".\GeneratedFiles\$(ConfigurationName)" UicDir=".\GeneratedFiles" RccDir=".\GeneratedFiles" lupdateOptions="" lupdateOnBuild="0" lreleaseOptions="" Qt5Version_x0020_x64="5.6-msvc2013_64" MocOptions="" />
</VisualStudio>
</ProjectExtensions>
Note that the value of the attribute Qt5Version_x0020_x64 should match the name of a Qt version in Qt VS Tools. You may set an arbitrary value and then fix it in Qt Project Settings in Visual Studio.
My setup
Visual Studio 2013
Qt VS Tools 2.0.0 Beta (apparently a rebranding of Qt VS Add-in)
Qt 5.6 msvc2013_64
Notes
When I follow Benjamin's answer and try to "Convert project to Qt VS Tools project", Visual Studio gets stuck.
The only Qt specific functionality I've tried with the project is exporting a .pri file.
I have reverse engineered the necessary modifications from a fresh VS project created using the template Qt GUI Application.
Converting a regular VC project to a QT project should be easier and the error message displayed by the Qt plug-in when attempting to add a Qt class to a non-QT project is exceedingly unhelpful especially when considering the actual differences between a Qt .vcprojfile and a non-Qt one are minimal. It is often the case that you have existing legacy code built into libraries and Dll's. During migration to Qt you may wish to add a Qt class to an existing module which was previously a non-Qt project. If the module has relatively few source files you may find it easier to re-create the project as a Qt project. If it has hundreds of source files or is complex in other ways it is often be easier to simply hand edit the .vcproj file. By comparing a regular .vcproj with a Qt one it is easy to see what the differences are:
A Qt project has a Keyword="Qt4VS1.0" immediately before
TargetFrameWorkVersion line near the top of the file.
At the bottom of the file you need to add the required Globals (in
particular QtVersion.Win32)
You will need to add the locations of the Qt header files to the
include paths (for all build configurations). You can do this later
via the visual studio user interface
For an exe or dll you will also need to add the Qt library locations
and library files to the linker options.
You actually only need to do 1 and 2 in a text editor and then you can reload the project in Visual Studio.
After setting up include paths and libraries you should be able to build the project as usual. Next you can add a new Qt class or convert an existing class into a Qt class. To do the latter first remove the source files for the existing class from the project otherwise the Qt add class wizard is likely to complain.
The above steps are intended for experienced users and you should always back up existing projects .vcproj files bfore hand editing. Simple mistakes here can render the file unusable.
More answer from Qt support engineer; I think the first pargraph is helpful as I didn't know that before:
i think this is a misunderstanding
really. If you have a Qt project
generated with the Add-in, then you
can change this project into a qmake
generated Qt project - and vice versa;
If you have a .vcproj that has been
generated by doing qmake -tp vc, then
you can convert this to a Qt Add-in
project.
There is no functionality to convert a
regular win32 project into a Qt
enabled project, so the suggestion
created is still valid, see:
https://bugreports.qt.io/browse/QTVSADDINBUG-27
I can see from the history of this
report that it has been closed and
re-opened again, so I assume there was
a misunderstanding regarding what you
were looking for in the first place.
If you create a .pro for you project
using qmake, then you should be able
to create a .vcproj file using 'qmake
-tp vc' on that .pro file. The qmake manual is available here:
http://doc.qt.io/qt-5/qmake-manual.html
I hope this helps.
Regards,
--
Support Engineer, Qt Development
Frameworks, Nokia