I've updated Visual Studio 2015 to Update 2 recently. Since then, I'm not able to compile my already published app anymore. Even a new blank UWP project does not compile. I get the following error message:
ILT0005: "C:\Program Files (x86)\MSBuild\Microsoft.NetNative\x86\ilc\Tools\nutc_driver.exe #"C:\Users\locked\documents\visual studio 2015\Projects\App1\App1\obj\x86\Release\ilc\intermediate\MDIL\App1.rsp"" Exitcode -1073740791
I completely uninstalled all Visual Studio relevant components and reinstalled them, which didn't solve the problem. Unfortunately, I'm not able to update my app at the moment.
I'm running Windows 10 Build 10586.218
It is a bug in .NET Native compiler, affecting German localization only (based on our current knowledge). We are looking into solutions (a fix with reasonable shipping vehicle, or better workaround). Stay tuned.
[Update] The fix shipped on 6th May as "Universal Windows App Development Tools - Tools (1.3.2)". Go to Control Panel - Programs - Programs and Features - Visual Studio ... - Modify, check Tools (1.3.2), then click Update. All languages now work (German, French, Italian, etc.).
-Karel Zikmund
(.NET Native team)
i had exactly this issue on french platform and found this solution : https://social.msdn.microsoft.com/Forums/en-US/9d590372-d82c-4075-9ea9-504a22c9502f/cant-compile-in-net-native-ilt005-error?forum=wpdevelop
compilation is ok after moved all ressources files nutcui.dll
Related
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
Here are the details about my local development environment:
-Windows 7 Professional
-Intel(R) Core(TM) i5-4590T CPU # 2.00GHz 2.00 GHz
-8 GB of RAM
-64-bit Operating System
-Microsoft Visual Studio Enterprise 2015 Version 14.0.25431.01
-.NET Framework 4.6.1
I change the "Microsoft Visual Studio Enterprise 2015 with updates" in Windows OS's "Programs and Features" so that I can add "Common Tools for Visual C++ 2015".
When I execute the change run, the update progress Misleadingly states that the updates ran properly.
However, it still does Not to install Visual C++'s "Common Tools for Visual C++ 2015" feature. I know this for a fact because if I change the "Microsoft Visual Studio Enterprise 2015 with updates" in Windows OS's "Programs and Features" then I get the following window with the Visual C++'s "Common Tools for Visual C++ 2015" being Unchecked:
Is it a technical limitation for Windows 7 Professional since I can't install Visual C++'s "Common Tools for Visual C++ 2015" feature?
This is a notorious problem with the VS2015 installer. It is not aggressive enough, it relies on the registry to determine if a sub-component is already installed. But doesn't actually verify if the files are still there, it solely uses the registry check. So if the registry is wonky then it goes through all the install motions, nothing seems to go wrong, but when it is done then it still doesn't work correctly.
Exactly what happened to the machine previously is pretty important to know, but everybody forgot what they did 2+ years ago. One notorious problem is previously having a preview version of VS installed. The uninstaller is always the last thing they get right just before shipping the RTM version. There is a clean-up tool available to fix that kind of registry pollution.
Noteworthy is that this problem is especially common for the "Common tools for Visual C++" sub-component. Almost certainly caused by this component also being available as a separate download. That download is supposed to be only used to setup a build server. But the predictable outcome is that somebody gets started on it on their own dev machine but then decide that they need VS instead.
There are a lot of threads at the MSDN Forums about this specific install problem. But they all suffer from the exact same issue, the Microsoft support people only get as far as "check this, check that" but none of them actually know how to repair the registry damage.
The only workaround I know that is reasonably successful is to aggressively uninstall. SO users never told me "it didn't work", but they also don't tell me "thanks dude, it worked". Odd btw, I can't tell how many of them just gave up and decided to reinstall the OS. You make it aggressive by starting the installer from an elevated command prompt and running it with /uninstall /force option. The /force option is the important one, it makes the uninstaller plow on even if the registry doesn't co-operate.
Since it is likely that the separate download was involved with is mishap, I'd start there. Download it again if you don't have it on the machine anymore. Next uninstall VS2015 the same way, do so even if the installer failed. If you have a reason to assume that the machine was exposed to a preview version then also use the cleanup tool. Might as well use it regardless, only way to be sure.
I have spent an incredible amount of time getting our product to run properly on customers' machines after we moved to Visual Studio 2015, and I still have one problem left to solve. The problem is that I can't get any of the C++ 2015 redistributables installers to work on 32-bit Windows 7 when it hasn't been patched (Windows Update).
The full story:
We upgraded all projects in the solution from VS 2013 to VS2015 and .NET 4.5.2, which also forced us to upgrade to "Microsoft Visual C++ 2015 Redistributable (x86/64) - 14.0.23506/23026)". We've done this kind of upgrade many times before, from VS2010 and up, and it never failed before.
23506 (for short) are the DLLs that accompany VS2015. We always found it easier to just XCOPY the DLLs into our installation folder. For some reason that doesn't work with the DLLs from VS2015 (23506). The program can't find them even when placed in the same folder as the executables. Why not?
Then I ran vcredist_xXX.exe that accompany VS2015, and the program runs fine.
But I want to XCOPY, so I discovered the download of 23026 from Microsoft, but there are no DLLs in there - only vc_redist.xXX.exe. Still, I copied the DLLs from somewhere in Windows - the paths to each DLL is listed in the registry. By the way, there are two extra DLLs installed that are not present in the folders in VS2015. "mfc140.dll" and "mfcm140.dll". Why?
But XCOPYing 23026 didn't work either, not even with the two extra DLLs. Running vc_redist.xXX.exe from 23026 worked fine.
Ok, problem solved, I thought. Using vc_redist.xXX.exe instead of XCOPYing. But no.
The final problem is that vc_redist.x86.exe (from 23026) and vcredist_x86.exe (from 23506) both fail when run on a 32-bit Windows 7 machine that hasn't been patched (Windows Update) at all after installation. For reasons I won't go into, that's the kind of machines we have to install our product on - unpatched 32-bit Windows 7 - no way around it. (The problem maybe exists on 64-bit unpatched Windows also, but I haven't got the time to find out.)
How do I get around this?
I am trying to link the C++ runtime statically and drop the DLLs alltogether, but it seems impossible when you have native C++ with C++ wrappers in a .NET project. This issue has already been reported by others, so no need to go into it here.
I have tried searching for DLLs to download, or a way to extract DLLs from the installer. Anyway, as mentioned above, I already tried just copying them from somewhere below C:\Windows. Doesn't work, so I doubt I can get some DLLs that will work. But again, why? If somebody can help me figure out this, it could be the perfect solution for our problem.
I have been thinking about finding the exact Windows patch(es) needed to get that installer - vc_redist.x86.exe - to work on those crappy machines. If it's just one or a handful of KBs that doesn't destabilize these machines, that would perhaps be acceptable.
A possibility that definitely should work is to downgrade the C++ projects to VS2013, which doesn't have this problem. I am really fed up of us always having to keep two versions of Visual Studio on our developer machines as a workaround for some silly problem, but if there's no other way, then so be it, even in 2016.
Found a quick and simple workaround. Turns out we only need to change the setting "Platform Toolset" to "Visual Studio 2013 (v120)" in all the C++ projects, in order to build with the good old DLLs that still work with XCOPY deployment. I was under the impression this setting would not go together with .NET 4.5.2, which we need, but it does. VS2013 will have to be installed along with VS2015, but we can live with that.
As stated, this is a workaround. It doesn't solve the actual problem stated in the title. But since I actually asked for a way around the problem, I'll close the issue with this answer.
As for the actual problem, if anyone is interested: I found some blog entries on the Visual C++ Team Blog - "Introducing the Universal CRT" and "The Great C Runtime (CRT) Refactoring". Where that leads, I'm not sure.
I was able to get this resolved on my local PC by following the updated step 6 on that article: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Once you copy the 20 or so DLLS folder it still didn't work for me, I had to grab the ucrtbase.dll and ucrtbased.dll along with all the usual 140 (mfc, mfcm,vcruntime, msvcp) from my SysWOW64 folder and finally i'm able to launch this on a windows 7 pc without requiring to install any patches!
I am making a small basic game for multiple mobile platforms using cocos 2dx, I have done all the coding in c++ on xcode and the project is running fine for iOS and android.
But when porting to windows phone I am facing a lot of hurdles. I am using cocos2dx 2.1.3 on visual studio 2012 express on 64 bit windows 8 with windows 8 phone SDK.
Firstly i don't get templates for cocos2dx, then there is no option to run the project in simulator or device. I have been digging the internet alot for this and have found some tutorials but all of them have one or the other limitations.
can somebody guide me with this windows part or a totally new way round to implement cocos2dx on multiple platforms ?
Option 1
Your going to have to open a new Direct3D project and follow the directions from here
Option 2
There are a couple build scripts available to generate project types for all platforms in python, as seen here.
(this works with 2.1.2 or later)
Option 3
Newer versions of cocos2d-x have build scripts for all platforms that come with the latest git repos. Not sure if there are a lot of breaking changes but the newer versions also have build projects.(build-win32.bat)
About the project template.
The templates for windows 8, at least in the last stable release I looked at a month ago, still had some issues with the html in the c++ project wizard but, the current development branch should have that fixed for the windows 8 visual studio browser. If they haven't then there are a couple of html meta-data tags that will need to be removed as they are depreciated in order for the project wizard to be usable.
I am learning how to build games in Visual C++ and when I upload them so friends can check them out, they all end up with messages saying it can not run. I did some research and found that it is because I am compiling against a Dynamic library instead of a static library. Correct me if I am wrong anywhere please. Upon further research, I found that a lot of people do not advise going this direction but instead include the files needed by my game.
How would I go about distributing my games to friends and make it real easy for them to just open up my .exe and play the game?
If you link to any DLLs, you also need to ship those along. If you produce a single .exe in your output, you probably need your friends to install the MS Visual Studio redistributable package for your version of visual studio. This is an example link for the VS 2010 one, but the one you give your friends should match your version.
There are essentially two options: Keep everything as-is and provide them with the runtime files (also named Microsoft Visual C++ * Redistributable Package or similar; the * has to be replaced with your version, e.g. 2005, 2008 or 2010). Downloads can be found on Microsoft's download site as well as in your Visual Studio installation folder (look for a folder called "Redist").
Alternative solution: In your project settings you're able to select the runtime environment (under linker options). Change your release build to use "Multithreaded" instead of "Multithreaded-DLL".