Compatibility with VS2010?

Feb 8, 2010 at 2:23 AM

Sweet project! I love the idea and really like the idea of not having to install the gargantuan DirectX SDK just to get the compiler.

But ... what's the compatibility story with VS2010? Will it work now? Can it be tweaked to work? Will it require a separate version targeting that platform? Almost all my work is in VS2010 now and I'd love to be able to give this a try.

Feb 10, 2010 at 8:31 PM

I'll be working on that maybe this weekend and probably have a new version by next week with VS2010 support.  The primary issues that need to be solved deal with the changes that were made to .Net 4.0.  In WPF 4, they upped the maximum pixel shader version to 3.0, up from 2.0.  Other than that, it will just be making the installer better, knowing what scripts to run to properly register the assemblies.

Feb 10, 2010 at 9:54 PM

Fantastic! I'm running the VS 2010 RC and have a PS project I'm working on right now. So if you need some testing, let me know.

Feb 11, 2010 at 6:51 AM

Alright, this took a lot less time than I was expecting.  I've posted an alpha 1.1 version with VS 2010 and .Net 4 support.

Let me know how your testing goes ;)

Feb 16, 2010 at 2:30 AM

I was traveling last week and didn't expect you to finish so soon :) I'm downloading it now and will let you know how it goes!

Feb 20, 2010 at 3:36 AM

Hope everything is going well :)  I've released a new version (1.5) that supports VS2010 much better than the 1.1 version I put out.  I recommend giving it a go.

Mar 2, 2010 at 6:34 AM


Sorry, It took me awhile to have a chance to play with it. I'm afraid I'm not having much success so far.

I've got a newly installed copy of VS2010 RC (with Intellisense patch) on a newly installed copy of Win7. I've got AnkhSVN, GhostDoc, and XAMLPowerToys installed. It should be a pretty clean test system and in general everything's working. The DirectX SDK was not installed, but the Win7 SDK was.

But when I create a test WPF project and then try to add a new WPF Shader Effect file, Visual Studio just crashes and shuts down completely (no error messages). I've tried adding the shader to both the solution project and creating a class library and adding it to that, but the result is the same. Looking at the solution folders afterwards I can see the Effect*.fx files being created but they don't make it into the csproj file.

I then tried uninstalling the other addins along with WPFShaderGenerator, rebooting and then installing WPF ShaderGenerator again so see if that helps -- same results.

I tried enabling VS logging, but I couldn't pick out anything helpful from it.

Any thoughts? I'm game to try some more tests if you have any suggestions.

Mar 2, 2010 at 8:38 AM


On a hunch, I tried installing the ActiveX SDK and it's working now. There must be some sort dependency on the ActiveX SDK in there somewhere. Anything I can do to help track it down?

Mar 2, 2010 at 10:09 AM

The ActiveX SDK?  Not sure how I could be using anything from there, I don't even have that downloaded.

Mar 2, 2010 at 10:27 AM

You could try using Dependency Walker to see what DLL is grabbing something out of the ActiveX SDK.

I don't see anything on my end that looks obvious though.

Mar 2, 2010 at 8:22 PM

Sorry, I meant DirectX SDK not ActiveX SDK! I did try Dependency Walker but again nothing jumped out at me. I'll try uninstalling the DirectX SDK and see if it breaks again. Perhaps I can pick something out in Process Monitor.

Mar 2, 2010 at 9:53 PM

That's pretty strange.  I uninstalled my DirectX SDK last night on a similar hunch, restarted and was still able to use the plug-in no problem in VS2010.  It's possible the SDK installs something else I need to package in the install.  Sucks they stopped distributing static libs for the d3dx lib.

Mar 3, 2010 at 12:59 AM

Ok, I think I've got it figured out.  You don't need to DirectX SDK because I package the d3dx9_42.dll that you needed like I thought.  However, you do need to make sure you have the latest DirectX Runtime to match it.  Because d3dx9_42.dll will load the D3DCompiler_42.dll (Thanks Process Monitor), which appears to be a product of the DirectX runtime and SDK.

In the next version of the installer, I'll be sure to include the web-installer for the latest DirectX runtime.

Mar 3, 2010 at 4:42 AM

Thanks for reporting the problem, I've updated the installer and released a new version including the latest DirectX runtime installer.

Mar 3, 2010 at 7:00 AM

Thanks -- I'm glad you figured it out!

But I'm a bit confused. Windows 7 comes with DirectX 11 already installed, correct? So what exactly is the DirectX runtime installer actually installing? Do you need an earlier version of DirectX to be installed? Don't the later versions of DirectX supercede the older versions?

In any case I'll download the new version and try it later tonight and let you know (I've reset my system to before the SDK was installed -- gotta love boot to VHD!).

Mar 3, 2010 at 10:08 PM

You are correct, however, Microsoft releases a new version of the DirectX SDK about every ~5 months, each time they update a dll in the runtime or the SDK they bump the version number on it, which is why you see _41.dll, _42.dll ...etc.  I dunno what version they shipped with Windows 7, probably 40 or 41.  But I built and linked against the latest version which just released in February.  Which is why a fresh Windows 7 install wouldn't have the _42.dll's associated with that release of the Runtime/SDK.

New versions versions of DirectX 9/10/11 runtime contain all the versions going back to like revision 32.  So as long as you have the latest installed you have all the previous versions :)  Let me know how your testing goes.  Is the VHD feature only available on ultimate?

Mar 3, 2010 at 11:32 PM

The latest test works great!

But while downloading a 90 MB DirectX is MUCH better than downloading the almost 1GB DirectX SDK, it'd be nice if we could find a way to skip that step too somehow. After the DirectX update I had D3DCompiler_33.dll through D3DCompiler_42.dll in the C:\Windows\System32 folder. On a virgin Win7 system though, none of those files were present. I take it that the DirectX runtime is loading a sort of mini-SDK along with the basic DirectX bits? That might explain why the runtime update is so large, because it's really loading a lot more than just the standard DirectX that comes pre-installed on machines. I think I say some comment about the DirectX SDK pass by on the installer window. I wonder if the DirectX update would be sufficient for Shazzam (as opposed to needing the whole SDK)?

Boot-To-VHD is a great feature, but only Win7 Ultimate (or Enterprise) supports booting that way unfortunately. It's mostly practical if you have an MSDN subscription so licensing isn't a problem. Scott Hanselman referred to it as "Less Virtual, More Machine" ( and that's a pretty good description. It's a lot like developing on virtual machines, but without loosing access to multiple monitors, nice video cards, speed, etc. It's easy to have VS2008 and VS2010 boots without worrying about trashing out my machine with beta versions, etc.

Mar 4, 2010 at 12:45 AM

Nah, for Shazzam, they're calling a shader compiler executable that ships with the SDK :(

So the 90MB download should be far less for most users, if you're up to date it's nothing.  If you're not up to date I believe it only installs the difference, so if you play games at all odds are you'll be much more up to date on your machine than a completely clean machine.

I could track down the static lib of d3dx9 and link against it instead of the DLL's lib.  However, that static lib is old, and they've stopped distributing it because of "security concerns", is what I read.  If I did that though, it would up the standard install size to like 20mb for everyone, vs. the 1.7mb it is now.

Auw, I've only got Windows 7 Professional.  Lame.

I'm glad it works now on a fresh install :D

Jun 11, 2010 at 4:00 AM
Edited Jun 11, 2010 at 4:00 AM

For Shazzam we are using the FXC.exe file that ships with the DirectX SDK.  FXC is  the command line compiler for shaders.   I want to remove our dependency on the SDK.  We've tried a couple times in the past and ran into the same issues with virgin Windows 7 install. 

I'd like to avoid installing the DirectX runtime too.   Is it still true that you have to have the runtime installed for your dx9fxutil.dll to work on a fresh Win 7 box?



Jun 11, 2010 at 6:22 AM

As far as I know yes, but I've not tried packaging a specific version of the runtime's set of dlls with the install and just putting them in the same directory as the tool.  Several games tend to do this even though they probably shouldn't.  Might work for this usecase as well.  Because these shaders are not full fx files, and only support a pixel shader and are realistically just a single HLSL function, you can just do what I've done and write a CLI/C++ wrapper around D3DCompiler_42.dll.  I could probably get away with a version of that and the dx runtime dll matching that version number and be set if I dropped those into the same directory as my VS plugin.

Jun 11, 2010 at 6:46 AM

I've got Shazzam working by copying d3dx10_xx.dll, D3DCompiler_xx.dll, D3DX9_xx.dll to the install folder.  Hooray.  You might want to test your app with those files,   

I looked at your wrapper, looks like you are calling D3DXCompileShader.  JMorrill wrote our PInvoke code  and it is calling D3DX10CompileFromMemory in the d3dx10_xx.dll.  I've tested on a clean Win7 VM and Shazzam successfully creates WPF and Silverlight shaders.


Jun 11, 2010 at 7:14 AM

Glad to hear it, I'll look into it for my next version.