Is there a comprehensive listing of platform toolsets and MSC_VER minor revisions?
I was digging for it today and can't find it.
Specifically I'm looking for VS2019 platform toolsets and MSC_VER corresponding to VS2019 releases 16.1.6 and 16.5.4. But a comphrehensive list will work better moving forward.
The Best information I found is at this link.
Visual Studio 2019 Build List
It's not ideal as it doesn't tie each one to a platform toolset.
That appears to be due to platform toolsets only existing for the first digit of minor rev, not second. So you can't be 100% sure the platform toolset will 100% match your specific downloaded release without testing.
Users can confirm a 100% match by adding the -Bv switch to the compiler options, this will dump Build versions for the compiler. This covers the build of the compiler/linker tools, but the *.h files and runtime libraries could be different possibly. Not sure.
So far this Wikipedia link contains a portion of the information. It only gets a partial list of minor revisions. For example 16.1 and 16.5 are listed but not 16.1.6, 16.5.4 but its close. My assumption is that the platform toolset for Visual Studio 16.1 would be v14.21.
I also show the Visual Studio 2019 installer which only provides the same level of detail.
From this I conclude that it is NOT possible to exactly match release 16.1.6, or 16.5.4 unless these are the LAST minor releases of the software. It's impossible to know that because there is no comprehensive list. So I can't say for sure that platform toolset 16.1 or 16.5 EXACTLY matches 16.1.6 or 16.5.4 because there is no comprehensive listing.
Related
I really feel like I shouldn't have to ask a question on SO to get basic information like this, but I can't find a reliable source anywhere.
Is WiX v4 released? In Development? In Beta? Still being designed?
Lots of people seem to already be using WiX v4, as evidenced by SO questions about it. And it has an official release page on the WiX site, without any mention of "Beta" or "Release Candidate", etc: http://wixtoolset.org/releases/v4-0-0-5205/
However, there are no released versions for v4 on GitHub: https://github.com/wixtoolset/wix4/releases
And the Wix homepage still directs you to download v3.
And one of the developer's blogs has a recent post about v4 that uses future-tense language like "will have" and "should support".
But worst of all, the current version of the WiX visual studio integration tools has templates for v4, which makes it seem like v4 is officially supported!
And when you try to build one of these templates the build error is The WiX Toolset v4 build tools must be installed ... To download WiX Toolset v4, see http://wixtoolset.org/releases/ despite the fact that http://wixtoolset.org/releases/ contains downloads exclusively for v3!
This is a crazy amount of mixed messages.
Is there something somewhere that says officially, definitively what state WiX v4 is in?
The previous answer is out dated. WiX v4 is very close to being ready and I encourage active testing of it during the RC phase.
In WiX v4, there is no installer for WiX. It's a dotnet tool you install. If your a user of Votive, Votive is no more. Instead FireGiant has a closed source but free replacement called HeatWave. This creates your .wixproj which is now an SDK style project. References to extensions are no longer DLL references but Nuget package references.
There is a tool to covnvert v3 schema to v4 schema called WiXCop. Heatwave will do this for you in a one time project by project conversion step.
WiX is no longer installed on the build server as msbuild will automatically install the SDK package references.
FireGiant reached out to be before the release and gave me a preview look. From this I was able to update my open source project IsWiX to completely support v3 or v4 using Votive or HeatWave.
All in all it's looking really good and once all the final bugs are gone I will be migrating all of my customers over to WiX v4.
WiX Toolset v4 RC2 was released on January 20, 2023. There are regular updates on the FireGiant blog that are helpful for tracking progress towards the final release. WiX v4 is now a .NET tool. This release contains many significant changes from v3.
WiX v4 does appear as a number of weekly releases which can be downloaded and installed. I've installed v4.0.0.5918, and it appears to work with the integrated Visual Studio WiX extension v4 projects, though I've not tested this extensively. The wxs project template looks identical to v3.
Considering the progress of v4, although I admit I'm quite new to this, I found a page here going back as far as end 2012!
http://robmensching.com/blog/posts/2012/12/12/the-wix-toolset-v4.0-begins/
A more recent article on WiX v4.0 and it's features can be found here
https://www.joyofsetup.com/tag/wix4/
Bug fix logs also imply v4 is being developed alongside v3, however indeed without formal confirmation, official releases, or any documentation whatsoever.
https://www.firegiant.com/blog/2015/6/2/wix-online-meeting-68-highlights/
https://www.firegiant.com/blog/2017/7/11/wix-online-meeting-130-highlights/
UPDATE
WiX v4 (preview) has just been released, for more information see the main page:
https://wixtoolset.org/docs/releasenotes/
https://wixtoolset.org/docs/intro/
I downloaded the WiX Toolset v4-rc.2 yesterday and was IMMEDIATELY disappointed. There is NO documentation giving even the slightest hint what the new XML schemas are and how they were related to or superseded v3. Also, nothing, NOTHING was done to support custom actions in .NET 6 or 7. These .NET versions have been available for several years now and Firegiant has had PLENTY of time to update all of this. I see NO ADVANTAGE whatsoever in moving to v4. Come on #robmen you are completely missing the mark on supporting this update. Do you seriously think the development community has the time to read your github v4 repository so we can discern how to use this update?? The only grace I extend to you is it is a tough job to support a product that has many users and each user's particular needs, but you decided to do this and you are failing miserably...
Actually, if this project had been open-sourced instead of taken private, the community would have advanced the functionality of this product by leaps and bounds over the years. I have been a WiX user since 2013 and it remains largely unchanged.
Case in point:
How long has .NET 5 been out?
How long has .NET 6 been out?
How long has .NET 7 been out?
.NET 3.5.1 is ridiculous...
I've been working in an engine in Visual Studio 2012 that supports rendering with Direct3D 9 and Direct3D 11. However I'm getting some new people to help with the project and they would prefer to work on Visual Studio 2010 because that's the version they own and use. So I decided to convert the project to be built with VS2010's v100 platform toolset.
I'm getting close to getting it to work but I can't include DirectXMath.h, necessary for the DirectXTK and some utility functions I'm using. It's part of the Windows 8 SDK and included in VS2012, but VS2010 doesn't seem to find it.
Anyone knows how to get it to be included using environment variables so that it works for everybody on the team, and in a way that works on Win7 too?
Thanks.
To make new teammates be able to code in VS2010 you have several options:
You don't need to change platform toolset to old one and rewrite your codebase. VS2010 developers can just install Windows 8 SDK, and use v110 toolset. To help them, configure "VC++ directories" in project properties as pointed in this article (change macro variables, which points to old Windows SDK, to explicit locations of new Windows SDK):
In “Executable Directories” replace $(WindowsSdkDir)binwith$(ProgramFiles)\Windows Kits\8.0\bin\x86`
In “Include Directories” add $(ProgramFiles)\Windows Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared at
the beginning and remove $(WindowsSdkDir)include
In “Library Directories” replace $(WindowsSdkDir)lib with $(ProgramFiles)\Windows Kits\8.0\lib\win8\um\x86
In “Exclude Directories” replace $(WindowsSdkDir)include with $(ProgramFiles)\Windows
Kits\8.0\Include\um;$(ProgramFiles)\Windows Kits\8.0\Include\shared
When targeting x64, replace x86 with x64
If you really want to downgrade toolset from v110 to v100, then you will need to make use old standalone DirectX SDK. Before, Windows SDK and DirectX SDK was separate. They was merged since Windows 7 SDK. When merging, Microsoft decidede to remove some stuff and also renamed some files, for example, standalone SDK contains math in #include <xmmath.h>.
You can combine both: create multiple project/platform configurations and inmplement conditional compilation via #ifdef where VS2010 configuration will fail to find headers/compile. For example you can use C++11 features in VS2012 branch of code, but in VS2010 branch you use only C++03 features.
I would prefer first option, but it is up to you to decide.
P.S. As far as I remember, project files from VS2012 (.vcxproj) cannot be opened in VS2010 (it knows only .vcproj), so you cannot share it. You will probably want to install VS2010, make .vcproj and maintain both files. It can be pain when you change project options in one, and forget to change in other, so be careful. Also, consider to move all your team to single IDE, or at least single build system (for example, CMake).
Happy coding!
I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.
I'm trying to compile MPIR (the Windows-friendly fork of GMP) from the command line. My setup is pretty bog standard, Windows Vista 32-bit, Visual C++ 2010 express edition, and I'm just going for a completely vanilla 32-bit static library build, not trying to use the IDE. The information I could find with a Google search says:
Install the appropriate version of yasm.
Go into build.vc10
Configure.bat
Make.bat
I managed to get as far as step 3 seeming to work, and past the first obstacle in step 4, but now it's tripping up on this line in make.bat:
%MS_BUILD% gen-mpir\gen-mpir.vcxproj /p:Platform=Win32;Configuration=Release
As far as the searches I've run can determine, there is no gen-mpir anywhere in the entire directory tree, nor any other reference to such. What am I missing?
Answer from the good folk on the mpir-devel mailing list: http://groups.google.com/group/mpir-devel/browse_thread/thread/488233bc8face88a
It seems like it's still not possible to build .vdproj on a build-server without having Visual Studio installed. However, using Wix seems to be a lot more complicated.
Are there any other options to do the following task:
Visual Studio 2010 Solution with multiple projects (.csproj)
Many loose content files (not inside assemblies)
Installer must be built on Build-server without Visual Studio on it (devenv.exe / devenv.com)
Installer must create Registry keys
Installer must associate file extensions with installed product
Installer must support upgrades (version upgrades)
Installer should be able to register COM components
Installer should be able to pre-JIT assemblies
My goal is:
Effort to maintain installer is low
Minimal changes if new project (assembly) is added to solution
Ideal: no changes if new content files are added to any of the projects
Maybe I just did not get the point with Wix, but including project output (like in .vdproj) seems very complicated.
Any suggestions very much appreciated!
OK I decided to go with Wix. Found out that using Votive it's possible to include project output like in .vdproj (Binaries, Content, Symbols and even Source Code).
If I run into more complicated situations where this isn't sufficient, I could fall back to some kind of harvester (Heat, Paraffin).
See some more Links in comments below (too little reputation to post more than 1 link in this post).
Check out InstallShield 2010 Limited Edition ( Free for Visual Studio 2010 users ). It has pretty much all the functionality that VDPROJ ( being retired btw ) has and supports silent builds. You can get one license for your dev box and one license for your build machine pretty easily.