CUDA 4.0 with VS2010 Strange issue with CUDA on VS 2010
I started off with the release candidates of the CUDA 4.0 toolkit and Parallel Nsight 2.0. Then when they went into production release, I uninstalled all my NVIDIA tools and installed the production releases of the CUDA Toolkit 4.0 and Parallel Nsight 2.0. When I tried creating a new CUDA project I followed the steps on Ade Millers blog. First setting my configuration to x64. Then this is where things always go downhill. When you highlight the project in the Solution Explorer tab and then go to Project->Build Customizations and select 4.0, Visual Studio behaves very strangely. First off, when I right click the .cu file and click Properties to select its "Item Type" as CUDA C/C++ I instead have the properties tab open?!? Then when I close the project and try to reopen it I get an error message that reads, "The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.0.targets". I've actually found a very strange workaround to fixing my project. Apparently if I delete the VC++ Project Filter File, load the project, and clean it, it will work. Yes, I am talking about the file responsible for separating the Source Files filter from the Header Files filter. However, this will only work on my previous CUDA program solutions. I cannot do this to new projects. To actually create a new project I click New Project->NVIDIA->CUDA 4.0 Runtime and set things up as usual. If you're reading this right now you're probably thinking why don't I just do the workaround? The answer is that I have a few parallel programming applications on the CPU that I want to extend to use CUDA and I don't to risk ruining them. If anyway has questions or insight about this a I'd appreciate a reply.

I've attached an example of a project that won't work.
I started off with the release candidates of the CUDA 4.0 toolkit and Parallel Nsight 2.0. Then when they went into production release, I uninstalled all my NVIDIA tools and installed the production releases of the CUDA Toolkit 4.0 and Parallel Nsight 2.0. When I tried creating a new CUDA project I followed the steps on Ade Millers blog. First setting my configuration to x64. Then this is where things always go downhill. When you highlight the project in the Solution Explorer tab and then go to Project->Build Customizations and select 4.0, Visual Studio behaves very strangely. First off, when I right click the .cu file and click Properties to select its "Item Type" as CUDA C/C++ I instead have the properties tab open?!? Then when I close the project and try to reopen it I get an error message that reads, "The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.0.targets". I've actually found a very strange workaround to fixing my project. Apparently if I delete the VC++ Project Filter File, load the project, and clean it, it will work. Yes, I am talking about the file responsible for separating the Source Files filter from the Header Files filter. However, this will only work on my previous CUDA program solutions. I cannot do this to new projects. To actually create a new project I click New Project->NVIDIA->CUDA 4.0 Runtime and set things up as usual. If you're reading this right now you're probably thinking why don't I just do the workaround? The answer is that I have a few parallel programming applications on the CPU that I want to extend to use CUDA and I don't to risk ruining them. If anyway has questions or insight about this a I'd appreciate a reply.



I've attached an example of a project that won't work.
Attachments

Example.zip

#1
Posted 05/28/2011 02:48 AM   
This is probably not much help to you, but I'm getting the same error in a different situation. I had a nicely working CUDA 3.2 / VS 2008 / Nsight 1.51 environment. Now that CUDA 4.0 came out, I uninstalled everything related to those components and installed VS 2010, Nsight 2.0 and CUDA 4.0 (in that order). For me, creating a new CUDA 4 project with the New | Project | CUDA 4.0 Runtime template works just fine. Using the Win32 project as basis for an x64 project works fine as well.

What fails for me, with the same error message that you're getting, is the Conversion Wizard that appears when I attempt to open any of old VS 2008 projects in VS 2010.

My projects aren't big, so a solution for me will be to just create new projects in VS 2010, copy the source files in and add them to the projects.
This is probably not much help to you, but I'm getting the same error in a different situation. I had a nicely working CUDA 3.2 / VS 2008 / Nsight 1.51 environment. Now that CUDA 4.0 came out, I uninstalled everything related to those components and installed VS 2010, Nsight 2.0 and CUDA 4.0 (in that order). For me, creating a new CUDA 4 project with the New | Project | CUDA 4.0 Runtime template works just fine. Using the Win32 project as basis for an x64 project works fine as well.



What fails for me, with the same error message that you're getting, is the Conversion Wizard that appears when I attempt to open any of old VS 2008 projects in VS 2010.



My projects aren't big, so a solution for me will be to just create new projects in VS 2010, copy the source files in and add them to the projects.

#2
Posted 05/28/2011 05:15 PM   
I believe your SDK solutions would have no problem. Open a solution in the SDK and copy the various settings over will perhaps do.

Studying the .vcproj file for a while may help you to create your own template as well.
I believe your SDK solutions would have no problem. Open a solution in the SDK and copy the various settings over will perhaps do.



Studying the .vcproj file for a while may help you to create your own template as well.

Working on a Fermi assembler.. for the fun of it! :)

#3
Posted 05/28/2011 09:14 PM   
[quote name='RogerDahl' date='28 May 2011 - 11:15 AM' timestamp='1306602934' post='1243598']
This is probably not much help to you, but I'm getting the same error in a different situation. I had a nicely working CUDA 3.2 / VS 2008 / Nsight 1.51 environment. Now that CUDA 4.0 came out, I uninstalled everything related to those components and installed VS 2010, Nsight 2.0 and CUDA 4.0 (in that order). For me, creating a new CUDA 4 project with the New | Project | CUDA 4.0 Runtime template works just fine. Using the Win32 project as basis for an x64 project works fine as well.

What fails for me, with the same error message that you're getting, is the Conversion Wizard that appears when I attempt to open any of old VS 2008 projects in VS 2010.

My projects aren't big, so a solution for me will be to just create new projects in VS 2010, copy the source files in and add them to the projects.
[/quote]

Nice to know I'm not the only one this is happening too. If you do figure anything out please post reply. Thanks.
[quote name='RogerDahl' date='28 May 2011 - 11:15 AM' timestamp='1306602934' post='1243598']

This is probably not much help to you, but I'm getting the same error in a different situation. I had a nicely working CUDA 3.2 / VS 2008 / Nsight 1.51 environment. Now that CUDA 4.0 came out, I uninstalled everything related to those components and installed VS 2010, Nsight 2.0 and CUDA 4.0 (in that order). For me, creating a new CUDA 4 project with the New | Project | CUDA 4.0 Runtime template works just fine. Using the Win32 project as basis for an x64 project works fine as well.



What fails for me, with the same error message that you're getting, is the Conversion Wizard that appears when I attempt to open any of old VS 2008 projects in VS 2010.



My projects aren't big, so a solution for me will be to just create new projects in VS 2010, copy the source files in and add them to the projects.





Nice to know I'm not the only one this is happening too. If you do figure anything out please post reply. Thanks.

#4
Posted 05/28/2011 10:53 PM   
[quote name='hyqneuron' date='28 May 2011 - 03:14 PM' timestamp='1306617253' post='1243672']
I believe your SDK solutions would have no problem. Open a solution in the SDK and copy the various settings over will perhaps do.

Studying the .vcproj file for a while may help you to create your own template as well.
[/quote]

I plan using NVIDIA->CUDA->CUDA 4.0 Runtime project for the rest of my work, but I'm still disgruntled at the fact that I had to recompile all my projects. I'm still looking for a total fix to this issue though...
[quote name='hyqneuron' date='28 May 2011 - 03:14 PM' timestamp='1306617253' post='1243672']

I believe your SDK solutions would have no problem. Open a solution in the SDK and copy the various settings over will perhaps do.



Studying the .vcproj file for a while may help you to create your own template as well.





I plan using NVIDIA->CUDA->CUDA 4.0 Runtime project for the rest of my work, but I'm still disgruntled at the fact that I had to recompile all my projects. I'm still looking for a total fix to this issue though...

#5
Posted 05/28/2011 10:58 PM   
I had the same issue ([i]The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid.[/i]) coming from a working 3.2 project/solution.

I resolved it by changing the project files as described in [url="http://stackoverflow.com/questions/6156037/issue-with-production-release-of-cuda-toolkit-4-0-and-nsight-2-0/6167915#6167915"]this stackoverflow answer[/url].
I had the same issue (The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid.) coming from a working 3.2 project/solution.



I resolved it by changing the project files as described in this stackoverflow answer.

#6
Posted 05/29/2011 01:17 PM   
[quote name='Simon_' date='29 May 2011 - 07:17 AM' timestamp='1306675039' post='1243874']
I had the same issue ([i]The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid.[/i]) coming from a working 3.2 project/solution.

I resolved it by changing the project files as described in [url="http://stackoverflow.com/questions/6156037/issue-with-production-release-of-cuda-toolkit-4-0-and-nsight-2-0/6167915#6167915"]this stackoverflow answer[/url].
[/quote]

Tried it, it's no good. Have you taken a look at the example I attached? BTW that was my question that you saw.
[quote name='Simon_' date='29 May 2011 - 07:17 AM' timestamp='1306675039' post='1243874']

I had the same issue (The result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid.) coming from a working 3.2 project/solution.



I resolved it by changing the project files as described in this stackoverflow answer.





Tried it, it's no good. Have you taken a look at the example I attached? BTW that was my question that you saw.

#7
Posted 05/29/2011 04:51 PM   
Order matters in MSBuild, and if you import your common targets (which is usually what serves to execute the compiler itself) *before* you've defined some other import it's going to use, then the import won't get called.

At the bottom of your .vcxproj file, you have:
[code]
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.targets" />
</ImportGroup>
[/code]

What happens if you change it to:
[code]
<ImportGroup Label="ExtensionTargets">
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.targets" />
</ImportGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />

[/code]

I haven't tried this, but it's just a guess from 30 seconds of looking at the problem. Also, if anyone is upgrading from Visual Studio 2008, the reason things are a bit different is that prior to VS2010, Visual C++ used its own, separate, build system (not MSBuild, like C#, VB.NET, and pretty much anything else); in VS2010, they overhauled the VC++ project system to be based on MSBuild...so if you want to get to the root of the problem, start learning about MSBuild. It's quite helpful once you've learned it a bit, since you can add lots of interesting customizations to your build process with it.
Order matters in MSBuild, and if you import your common targets (which is usually what serves to execute the compiler itself) *before* you've defined some other import it's going to use, then the import won't get called.



At the bottom of your .vcxproj file, you have:



<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />

<ImportGroup Label="ExtensionTargets">

<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.targets" />

</ImportGroup>




What happens if you change it to:



<ImportGroup Label="ExtensionTargets">

<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.targets" />

</ImportGroup>

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />






I haven't tried this, but it's just a guess from 30 seconds of looking at the problem. Also, if anyone is upgrading from Visual Studio 2008, the reason things are a bit different is that prior to VS2010, Visual C++ used its own, separate, build system (not MSBuild, like C#, VB.NET, and pretty much anything else); in VS2010, they overhauled the VC++ project system to be based on MSBuild...so if you want to get to the root of the problem, start learning about MSBuild. It's quite helpful once you've learned it a bit, since you can add lots of interesting customizations to your build process with it.

GPU.NET: Write your GPU code in 100% pure C#.

Learn more at tidepowerd.com, and download a free 30-day trial of GPU.NET. Follow @tidepowerd for release updates.



GPU.NET example projects

#8
Posted 06/01/2011 02:55 AM   
[quote name='seljuq70' date='27 May 2011 - 07:48 PM' timestamp='1306550921' post='1243342']
... However, this will only work on my previous CUDA program solutions. I cannot do this to new projects. To actually create a new project I click New Project->NVIDIA->CUDA 4.0 Runtime and set things up as usual. If you're reading this right now you're probably thinking why don't I just do the workaround? The answer is that I have a few parallel programming applications on the CPU that I want to extend to use CUDA and I don't to risk ruining them. If anyway has questions or insight about this a I'd appreciate a reply.

I've attached an example of a project that won't work.
[/quote]

I have similar problems. I just got Cuda toolkit 4.0 64-bit and installed it on Win XP-x64 SP1 with current updates. I had Visual C++ Express 2010 already recently installed, with updates sufficient to enable 64-bit compilation.

Everything seems fine until I try to compile a project with a .cu file in it. If I enable the "cuda 4.0..." entry in the "build customization files" section, the IDE behaves strangely. For example, I can't effectively get properties on the project by right-clicking on it. Once this happens, I can not restore order by turning off the "cuda 4.0..." customization. I have found no technique that will make it compile the .cu file. I have tried remaking the project various ways. The best I get is the <result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid> message.

So, it looks like there must be at least two problems. Something a little bit wrong with the Cuda 4.0 MSBuildExtensions and something wrong with the IDE itself.

Is there a recommended fix or workaround for this? This is a SHOWSTOPPER problem on my current project. I am very surprised by this, since I have used other versions of the toolkit with not much difficulty.
[quote name='seljuq70' date='27 May 2011 - 07:48 PM' timestamp='1306550921' post='1243342']

... However, this will only work on my previous CUDA program solutions. I cannot do this to new projects. To actually create a new project I click New Project->NVIDIA->CUDA 4.0 Runtime and set things up as usual. If you're reading this right now you're probably thinking why don't I just do the workaround? The answer is that I have a few parallel programming applications on the CPU that I want to extend to use CUDA and I don't to risk ruining them. If anyway has questions or insight about this a I'd appreciate a reply.



I've attached an example of a project that won't work.





I have similar problems. I just got Cuda toolkit 4.0 64-bit and installed it on Win XP-x64 SP1 with current updates. I had Visual C++ Express 2010 already recently installed, with updates sufficient to enable 64-bit compilation.



Everything seems fine until I try to compile a project with a .cu file in it. If I enable the "cuda 4.0..." entry in the "build customization files" section, the IDE behaves strangely. For example, I can't effectively get properties on the project by right-clicking on it. Once this happens, I can not restore order by turning off the "cuda 4.0..." customization. I have found no technique that will make it compile the .cu file. I have tried remaking the project various ways. The best I get is the <result "" of evaluating the value "$(CudaBuildTasksPath)" of the "AssemblyFile" attribute in element <UsingTask> is not valid> message.



So, it looks like there must be at least two problems. Something a little bit wrong with the Cuda 4.0 MSBuildExtensions and something wrong with the IDE itself.



Is there a recommended fix or workaround for this? This is a SHOWSTOPPER problem on my current project. I am very surprised by this, since I have used other versions of the toolkit with not much difficulty.

#9
Posted 08/04/2011 12:27 AM   
Here is an update.

I manually added an <ImportGroup Label="ExtensionSettings"> containing <Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.props" />.

Now, I get an error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.0\bin\nvcc.exe" -gencode=arch=compute_13,code=\"sm_13,compute_13\" --use-local-env --cl-version -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.0\include" -G0 --keep-dir "x64\Debug" -maxrregcount=0 --machine 64 --compile -D_NEXUS_DEBUG -g -Xcompiler "/EHsc /nologo /Od /Zi /MDd " -o "Debug-temp\TempInt400Cuda.cu.obj" "C:\test_code\Release_402_h_64\Encoder\TemporalInt\TempInt400CudaMex\TempInt400Cuda.cu"" exited with code -1.

Why does it "exit with code -1?" Is it because i am trying to do 64-bit with visual c++ express and the windows sdk 7.1? Does it need an older c++ compiler on the back end?

If I pass --verbose to nvcc, it does not tell me anything more. i can even specify --dryrun and it makes no difference.
Here is an update.



I manually added an <ImportGroup Label="ExtensionSettings"> containing <Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 4.0.props" />.



Now, I get an error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.0\bin\nvcc.exe" -gencode=arch=compute_13,code=\"sm_13,compute_13\" --use-local-env --cl-version -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v4.0\include" -G0 --keep-dir "x64\Debug" -maxrregcount=0 --machine 64 --compile -D_NEXUS_DEBUG -g -Xcompiler "/EHsc /nologo /Od /Zi /MDd " -o "Debug-temp\TempInt400Cuda.cu.obj" "C:\test_code\Release_402_h_64\Encoder\TemporalInt\TempInt400CudaMex\TempInt400Cuda.cu"" exited with code -1.



Why does it "exit with code -1?" Is it because i am trying to do 64-bit with visual c++ express and the windows sdk 7.1? Does it need an older c++ compiler on the back end?



If I pass --verbose to nvcc, it does not tell me anything more. i can even specify --dryrun and it makes no difference.

#10
Posted 08/04/2011 07:34 PM   
Scroll To Top