This C++/WinRT announcement states "What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK."
However if one delves one click further one finds that the "Windows 10 Preview Build of the SDK [is] to be used in conjunction with Windows 10 Insider Preview (Build 17025 or greater)" and "Installation on an operating system that is not a Windows 10 Insider Preview build is not supported and may fail."
Right now must one install a Windows Insider Preview of Windows 10? This is either a scary and lengthy process or straight impossible depending on one's admin rights.
Or can one grab the SDK and use the C++/WinRT bits on a box with a standard Windows 10 build?
Is the easiest route for some aspects of the C++/WinRT toolchain still GitHub?
How about if one is developing on a non-Windows-10 box, e.g. Windows 7? Zillions of commercial developers are in this situation and aren't in control of that.
Will the situation change and if so when?
Going forward does one wait for periodic updates to SDK previews, and if so how does one consume them?
Preview versions of the Windows SDK will not install on a non-Insider build of Windows. This is a restriction of the Windows SDK and not specific to C++/WinRT. In the long run (once RS4 ships) this won’t be a problem since you’ll be able to install the final Windows SDK for RS4 without this restriction.
In the short term, you need an Insider build of Windows to install the SDK, but you can then use that to target previous versions of Windows. I’m not sure whether it would work on Windows 7, but I don’t think that any developer using C++/WinRT would care to use Windows 7 when the Windows Runtime isn’t even available on that version of Windows at all.
The cppwinrt.exe compiler also relies on Windows 10 APIs to function. While this isn’t a dependency of code built with C++/WinRT, it is a requirement for building C++/WinRT components. Of course, the resulting binaries can then be executed on older versions of Windows, provided you handle light-up in the usual ways, such as with delay-loading.
Related
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 have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
I might need to write some GUI application that runs on .Net (and Windows), while what I can work with is Mono (on Ubuntu and/or Gentoo). I am very familiar with Python; in addition, I understand that the Mono Windows.Forms assemblies seem to be satisfactorily usable (I've run successfully .Net applications using Windows.Forms).
What are the steps I would have to take to have an environment where I can develop stand-alone IronPython on a GNU/Linux maching? Also, I would very much appreciate some .Net-Mono compatibility pointers (e.g. things I should know or avoid).
I'm not looking for an IDE; I'm quite at ease using vim for my editing purposes, and I don't mind building GUIs programmatically.
Note: what I'm actually asking, is help with the following:
I obviously have to install IronPython; so I make sure my Mono packages are installed, then I run the IronPython installer (using Mono, obviously) just like I would on Windows? Will this make the IronPython assemblies available to Mono? If not, how can I do that? Ubuntu 9.10 has a package for IronPython, but it's not the latest version; at the same time, for compatibility purposes, I can't upgrade the Ubuntu installation. I can't find an ebuild for Gentoo.
Do I have to install any more assemblies?
After I successfully install IronPython, how do I create a .Net/Mono executable from my IronPython sources? Is there a “proper” way?
Is there a way to “embed” the IronPython (and any other required) assemblies in the final .exe?
Check Windows Forms section on IronPython Cookbook for hints about creating Windows Forms applications.
As to the environment, I would write the app in Mono and check it works on Windows. I would set up two virtual machines and any source control system to transfer sources between them.
The key part is to write and run tests so you can verify it works on both platforms. So you cannot use just GNU/Linux machine to be sure. But I think you can install Windows 7 for 30-days trial period.
I used to write WinForms tests so here is link to my blog and several other articles:
GUIAT blog
Acceptance Testing .NET Applications using IronPython
Functional Testing of GUI Applications
IronPython says it requires Reflection.Emit and lightweight code generation. FAQ iOS tends to frown on that kind of thing. So if you want to do iOS, you may be out of luck.
I am developing a Compact Framework 3.5 application for Windows CE 6.0. Help.ShowHelp() throws a NotSupportedException. At windowsembedded.com I found this statement:
"Help is not included in the Core run-time because it requires a browser."
Is this the reason for the exception? If so, is there any recommended way to get around this issue or do I need to build my own help system?
ShowHelp uses the browser control (via webview.dll IIRC) under CE. The browser control is definitely part of the Professional CE license SKU (assessment tool here. There used to be a Word doc that listed every component, but I can't seem to locate a download for it), so you will have to roll your own Help framework if you intend to stay with a Core license. Options might be to use Opera or MiniMo as a browser, but you'd still have to roll all of the searh/help stuff.
Using RTF might be simpler.