Please vote to support request for DirectX tools for C#

Started by
8 comments, last by AlexandreMutel 11 years, 1 month ago

Hi all,

I have put a request up on VisualStudio.UserVoice for Visual Studio to provide HLSL compilation, and other DirectX related features such as shader designer and model editor to C# projects in the same way that they are provided for C++ projects. Please help the vote along as it's really important that C# be treated equally with regards to DirectX development. These features could be easily provided to C#. And would make working with DirectX easier for C# developers.

Here is the link to the VisualStudio.UserVoice suggestion ..

Enable HLSL, DirectX and graphics development toolset for the C# language.

Visual Studio only provides hlsl compilation tools for C++ projects, while C# projects which also use hlsl are left without this facility. This is a glaring inconsistency in the tools provided to each language. C# is meant to be a first-class language yet the DirectX tools which are built in to Visual Studio are not equally provided to C#, this is an unnecessary and arbitrary limitation.

Developing DirectX applications with C# is becoming easier and there are now more tools than ever to work with this combination of technologies, including SlimDX and SharpDX, both fully capable managed DirectX frameworks (wrappers). Please provide C# developers with hlsl compilation, and for that matter, all the DirectX and graphics related tools that are provided to C++ developers, including the shader designer and the model editor. These features are equally usable by C#/DirectX developers as for C++/DirectX developers.

Thanks for any support.

Advertisement

I am definately voting for this. This would be awesome, since XNA is apparently being discontinued it seems like microsoft is doing nothing when working with C# and DirectX together.

I don't get it. How do the tools not work with C#? Their shader compilation support is just an MSBuild task that runs FXC. No reason you couldn't also use it in your C# project; it's hardly language specific.

Mike Popoloski | Journal | SlimDX

@Mike - are you saying that hlsl compilation does work with C#, or can, because I don't see it. And I was told on MSDN after some other inquires that

'The HLSL compiler you're looking for is only present in C++ projects, for C# you're on your own.'

It may be that it can be configured (somehow) - but I have no idea how to do it, and VS2012 was touted as having all these new features for DirectX and graphics development, but they are not made available for C# projects.

I'm not sure whether you are criticizing my suggestion or if you are having a go at Microsoft.

FXC is a separate program used to compile HLSL shaders, which is what Visual Studio uses under the hood. It's not a function directly integrated into the IDE and only available while a C++ project is loaded. You can just as easily invoke FXC yourself and use it in your own projects as a pre/post-build event for example.

I think Microsoft's standpoint is going to be that there's no reason to put all this stuff in front of C# users because there is officially no C# support for DirectX. The third party libraries are great, but Microsoft isn't going to spend time configuring their IDE for their use.

I don't agree with that logic at all Flimflam, they might not be delivering a managed DX product, but that in no way prevents them from providing features to support product development. Especially when they do support those products already, hlsl notably. They included the graphics diagnostics for C# projects, they shouldn't have done that if your logic was a part of their political standpoint, can you explain that ?

There is no natural law that says C# and DirectX can't mix. But you are implying that there is, and more importantly that Microsoft subscribes to that law. I don't believe that's true. I believe that if enough people speak up and say 'hey, we are using DirectX with C#, and we want fair integration of the supporting technologies' then Microsoft will listen and possibly spend time configuring their IDE. You can't talk me down mate, or convince me that it's too hard, too expensive or would take too much time. Coz that's a load of crap honestly. They can do it, they can spend the time and they can afford to.

Hi Gavin,

I don't disagree with what you are saying - the HLSL actions taken for a C++ project should be easy to add to a C# based project. I haven't tried it, but I take you at your word that it doesn't work... I wish you good luck with your petition.

In the mean time, have you tried just adding a C++ project to your solution specifically for authoring your shader files? That would allow you to utilize the build capabilities for generating the compiled shader and also the syntax highlighting as well. Again, I haven't tried this, but it should be almost trivial to set up, get your project dependencies configured to build the HLSL project first, and viola - you have a work around.

It might be a useful option, because you don't know how long it will take for the support to get added, if at all.

Interesting idea Jason, I'll look into it.

The UserVoice suggestion has finally made it to page 1 of the C# section, with a 144 votes, not bad. But I think a long way from getting the attention of the Visual Studio team. But at least it's there and votes are steadily adding up. Sure, I may lack confidence in the UserVoice system actually making real change, but it never hurts to be pro-active.

Thanks Jason for the work-around, it has certainly proved an easier way to compile my shader code. In practice, it gives me the same experience.

Thanks everyone who has voted so far :)

It is not possible to straightly use their C++ VS/msbuild integration, as their are using custom C++ property pages that are only accessible from a C++ project (C# projects doesn't have such a feature of being extendable just by providing some xml formats for new property pages. In order to do this, you need to develop a new VSPackage that supports FlavoredProject). Sure you can use the msbuild task, but considering that It would be almost the same as calling the fxc compiler yourself, It is not really worth it.

The workaround described by Jason is the only way to use this infrastructure quite easily.

This topic is closed to new replies.

Advertisement