OpenCL: Strong name validation failed while creating a new opencl project - visual-studio-2010

This is the OpenCL first tutorial I am following.
I am unable to create new OpenCL project. When I try to create new OpenCL project in visual studio 2010 on windows 7, 64 bit , I get "Strong name validation failed. (Exception from HRESULT: 0x8013141A)" error. And thus it fails to create new project.
Reading some forum says, I have to do some thing with the dll . But I have no idea what is being said.
Some advice is at :http://www.lookout.net/2006/04/bypassing-strong-name-verification-for.html which ask me to do this:
sn -Vr *,36e4ce08b8ecfb17
But what do I put for 36e4ce08b8ecfb17, this is the name of the assembly, but what is the name of the assembly in my case? I am facing this issue at the beginning, when I just try to create New OpenCL project.
Can some one give me a hint specific to OpenCL ?
Then I click OK , and I get this:
What I tried
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -Vl
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Assembly/Strong Name Users
===========================================
*,* All users
iisresolver,B03F5F7F11D50A3A All users
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -Vr * ,B03F5F7F11D50A3
A
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Failed to open registry key -- Unable to format error message 00000005
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -Vr iisresolver , B03F
5F7F11D50A3A
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Failed to open metadata scope on iisresolver -- The system cannot find the file
specified.
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -Vr * , *
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Failed to open registry key -- Unable to format error message 00000005
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>
After I used elevated permission of CMD
C:\Windows\system32>sn -Vr * ,B03F5F7F11D50A3A
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Verification entry added for assembly '*,B03F5F7F11D50A3A'
No gain here , so tired this:
C:\Windows\system32>sn -Vr * ,*
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Verification entry added for assembly '*,*'
C:\Windows\system32>
Unfortunately no gain.

this is an annoying issue that can easily be sidestepped for development purposes.
To disable the strong name validating, simply open the visual studio command-line (for example, in Windows 7: Start >> All Programs >> Microsoft Visual Studio 2010 >> Visual Studio Tools >> Visual Studio Command Prompt (2010) )
Then type sn -Vl which will return you a list of all the assemblies registered for strong name validation.
Then type sn -Vr *,idnumberhere to disable the strong name validation for that assembly.
In the case of the error you are receiving ( Failed to open registry key -- Unable to format error message 00000005), this is most often related to permissions: your username may not have the necessary permissions to change strong name validation hence change the permissions on C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA to allow full access to your username as well and all should be fine again:)
Also, ensure that you run the VS command-line with elevated privileges so select Run as Administrator.
Hope this helps. :)
Let me know if you need more information as well though:)

This error is probably due to error Windows Registry try to modify it
or
install Intel or AMD OpenCL SDK on your machine, try to create the project again
or Update the include and library paths of the project to load the required information from the OpenCL SDK installed

I had this same exact problem today, and unfortunately, wasn't able to get it to work using sn.exe.
However, a workaround that worked for me was to just use one of Intel's sample programs as a starting project, and modify it from there. (For example the basic capabilities sample)

Related

DCompositionCreateDevice2: E_INVALIDARG One or more arguments are invalid

Having an unusual problem running Win32C++ source codes with the function DCompositionCreateDevice2, which is compiled with VS 2015.
The source codes compile without any error but display the above runtime error. Recompiling and running the same source codes with VS 2019, there is no runtime error.
The test sample codes are Windows SDK samples listed below:
TouchInputDirectManipulation
DCompV2BackfaceandD2DBatching
Any idea what could be the source of this problem? I am working on WTL open source project, and do not want to restrict the build environment to VS 2019.
This is actually an unusual issue... What happens is Microsoft has seriously messed up dcomp.lib between the Windows 8.1 SDK and the Windows 10 SDK.
Here is what you see if you dump the Windows 8.1 SDK dcomp.lib exports:
C:\>dumpbin "C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\dcomp.lib" /exports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Exports
ordinal name
DCompositionCreateDevice
1017 DCompositionCreateDevice2
DCompositionCreateSurfaceHandle
And here is what you see if you dump the Windows 10 SDK dcomp.lib exports:
C:\>dumpbin "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64\dcomp.lib" /exports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Exports
ordinal name
DCompositionAttachMouseDragToHwnd
DCompositionAttachMouseWheelToHwnd
DCompositionCreateDevice
DCompositionCreateDevice2
DCompositionCreateDevice3
DCompositionCreateSurfaceHandle
As you can see the DCompositionCreateDevice2 was defined with ordinal 1017 initially. When you build your program using the Windows 8.1 SDK (which is how theses samples are currently defined), you get that using dumpbin:
C:\>dumpbin c:\mypath\TouchInputDirectManipulation\cpp\x64\Debug\DirectManipulationSample.exe /imports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Section contains the following imports:
dcomp.dll
140054570 Import Address Table
140054E98 Import Name Table
0 time date stamp
0 Index of first forwarder reference
Ordinal 1017
So, your .exe is linked to ordinal 1017, not to exported name DCompositionCreateDevice2.
The problem is, with Windows 10 (I think you're running on Windows 10), dcomp ordinal 1017 is not DCompositionCreateDevice2 but DCompositionAttachMouseDragToHwnd! This can be confirmed if you debug your program, you land into that function that doesn't like what you send to it and reports E_INVALIDARG.
So the solution is to change the SDK if you target Windows 10:
Or simply use GetProcAddress("DCompositionCreateDevice2") etc. to dcomp.dll to make sure you get the good one.
This should be reported to Microsoft I guess...

Not able to run nmake on windows, link given on the body

I am trying to build the source of CURA; (Link: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Windows). I followed the instructions but got error as below:
PS D:\work\cura-build-environment-master\build> nmake
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.
It looks like you may not have followed all of the instructions, such as this one in the Microsoft Visual Studio 2019 section:
When building files (using cmake or nmake) in the steps below be sure to use the 'VS2015 x64 Native Tools Command Prompt'. This ensures that the Visual Studio 2015 build tools are used.

Different Paths To msbuild in VS2017

OS: Microsoft Windows [Version 10.0.14393]
VS-Version: 2017 Community
When I run vswhere.exe I get the following back and based on on the official vswhere documentation I can build the path to msbuild and this seems to work:
C:\Users\user\Desktop>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
Visual Studio Locator version 1.0.62 [query version 1.10.80.60812]
Copyright (C) Microsoft Corporation. All rights reserved.
[...]
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
[...]
C:\Users\user\Desktop>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe"
Microsoft (R)-Buildmodul, Version 15.1.1012.6693
If I start the developer command prompt located in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsMSBuildCmd.bat" I get the following result:
C:\Users\user>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsMSBuildCmd.bat"
**********************************************************************
** Visual Studio 2017 MSBuild Command Prompt
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\Users\user>where msbuild
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Why and what is the second path returned after starting the developer command prompt
I always use the first path ("C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe") to call msbuild for building C/C++/VC++ Projects. Is this in someway wrong?
VS 2017 switched to local copies of msbuild, if you used a VS 2015 command prompt, you would see a different global path.
The where command lists all the matching executable files that it finds on the PATH, but only the first one will be used by the command prompt when you run an msbuild command.
The second msbuild.exe you see is part of the .NET Framework - this is the version of MSBuild that was integrated into and shipped as part of the .NET Framework. This version is old compared to the ones installed by recent versions of Visual Studio. But it will likely be continued to be included in .NET Framework for compatibility reasons. It is even able to build a lot of projects that will then use the targets and tasks installed by VS - only project format changes that required changes to MSBuild itself will be incompatible (like the new project format used for .NET Core projects).
You should always use the VS 2017 version of msbuild.exe to always get build results consistent with visual studio.

Building WiX on Visual Studio Team Services times out

I have an existing XAML build I am porting over to Visual Studio Team Services build. There is a Solution file that contains two wixproj projects, and this builds with no issues on the current (legacy XAML) Hosted Build Controller (which uses WiX Toolset v3.7).
In VS TS, I created a new build process and added a step to Build solution using a Visual Studio Build step. I have set the Solution path to my sln that contains the two wixproj projects. All the other options are the defaults except the timeout which is set to 10 minutes.
The build step initiates but times out after calling the Light.exe step, as in the log below:
PrepareForBuild:
Creating directory "obj\Debug\".
Creating directory "bin\Debug\".
Compile:
C:\Program Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset Linker version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
##[error]The task has timed out.
The build will run 10 minutes and then throw a timeout error. It usually takes ~1 minute to finish. There is no information in the log about where this may be timing out or why.
I see that VS TS Build uses WiX version 3.10, but WiX version 3.10 works for me locally to build this same sln. I haveve tried all options for Visual Studio Version in the build step with same results.
Any ideas what I am missing and why this isn't working?
I found a post in the wixtoolset GitHub project documenting a bug in WiX 3.10 about deadlocks occurring with WiX projects if there are any warning or error messages generated during the build.
The workaround is to add the following MSBuild Arguments in the build step:
/p:RunWixToolsOutOfProc=true
This resolved my issue with the Light.exe process timing out.
Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset

SGEN doesn't work after upgrading from VS2008 to VS2010

I just recently upgraded a VS2008/.NET 3.5 SP1 project to VS2010 and .NET 4. I have a post-build event which calls SGEN to generate the XmlSerializers assembly.
Whenever I try to run it I get the following error.
"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sgen.exe" /debug /force /verbose /c:"platform:x86" "C:\path\to\SomeAssembly.dll"
Microsoft (R) Xml Serialization support utility
[Microsoft (R) .NET Framework, Version 2.0.50727.3038]
Copyright (C) Microsoft Corporation. All rights reserved.
Error: An attempt was made to load an assembly with an incorrect format: c:\path\to\someassembly.dll.
- Could not load file or assembly 'file:///c:\path\to\someassembly.dll'
or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
If you would like more help, please type "sgen /?".
I get the same error running SGEN from the command line, but I can't figure out what the problem is. Any ideas?
Seems like that second line of output from SGEN is important:
[Microsoft (R) .NET Framework, Version 2.0.50727.3038]
I found another version of SGEN which seems to work at C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\sgen.exe. It outputs this when you run it:
[Microsoft (R) .NET Framework, Version 4.0.30319.1]
I'm not sure why both are included in the Windows 7 SDK...
Yes, there are two versions of sgen.exe available, one for CLR v2 assemblies, the other for CLR v4 assemblies. It bombs because you ask the v2 version of sgen.exe to process a v4 assembly.
Check how your project gets sgen.exe started. If it is a post-build event then you'll have to tweak the path to sgen.exe. I don't see a macro or environment variable to get it right automatically, bit of an oversight.

Resources