Native Binaries: Visual Studio plugin generates incorrect solution file version

I took a shot at generating some visual studio project and solution files from a simple example project, and ran gradlew <component-name>VisualStudio. I have no lines whatsoever customizing the configuration of this task. I just added apply plugin: 'visual-studio' to the build.gradle file.

The generated solution file had this content at the top:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual C++ Express 2010

…but that content does not correspond to the content you get for the latest installed version of Visual Studio on my system, which is Visual Studio 2013. That content looks like so:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.31101.0
MinimumVisualStudioVersion = 10.0.40219.1

So, I’m wondering if I need to take additional steps in the visual studio plugin to instruct it to generate solution and project files that correspond to the version of Visual Studio that is used to build the binaries?

Hi Hoobajoob,

The Visual Studio plugin is generating Visual Studio 2010 compatible solution with NMake projects. Although the solution opens up as MSVC2010 in VS 2013, it will use the toolchain specified in your build.gradle script. It’s basically a pass through to gradle from VS. If you find the warning annoying, you can write the following code in your build script:

model {
  visualStudio {
    projects.all {
      projectFile.withXml {
        asNode().@ToolsVersion = "12.0"

        // Set platform toolset so you don't end up using VS2010 directories
        asNode().PropertyGroup.findAll({ it.@Label == 'Configuration' }).each { configNode ->
          configNode.appendNode("PlatformToolset", "v120")

I’m currently working on a better solution that will hopefully fix those issues. For now, you need to do it through XML manipulation.

Don’t hesitate if you have any other questions!

Thanks for the project file content modifier - I hadn’t looked at the project content yet.

The different version info in the solution and project files is in the nuisance category, but on systems with multiple VS versions installed, the Windows file explorer will display the .sln file with the corresponding version icon and if you have that matching version installed, the Windows launcher will start that version (instead of the version selected for building) when you double-click on it.

To get the solution file lined up too, I’m using this block, which works on my system:

      solutions.all {
          solutionFile.withContent { TextProvider content ->
              content.text = content.text.replaceAll( "Microsoft Visual Studio Solution File, Format Version [0-9]+\\.[0-9]+",
                                                   "Microsoft Visual Studio Solution File, Format Version 12.00")
              content.text = content.text.replace( "# Visual C++ Express 2010", "# Visual Studio 2013" )
              def builder = content.asBuilder()
              def versionIndex = builder.indexOf("# Visual Studio 2013" )
              builder.insert(versionIndex + 20, """
VisualStudioVersion = 12.0.31101.0
MinimumVisualStudioVersion = 12.0.21005.1

…but this seems like it could be brittle, as it assumes that by default the generated content will be using Format Version and commenting with # Visual C++ Express 2010.

How are these entries arrived at? If the visual studio task is run on different systems with different versions of Visual Studio installed, will the Format Version and Visual C++ Express 2010 lines have different values?

Also, another question: is there a way to get the solution file to use relative paths to the project files instead of absolute?



content.text = content.text.replace( project.projectDir.getAbsolutePath(), ".")

You can ignore this question!

You are totally right that having multiple Visual Studio installation would be annoying regarding which one it open. I will take that into account in my PR. The values in the vcxproj and sln files are simply taken from a template ( Part of the work I’m doing would be to expose more values from those template and fill them with the appropriate value. We can move the discussion to the dev forum (!forum/gradle-dev) if you have other request/concern regarding improvement to the VS plugin.

You solution for the sln and my solution for the vcxproj is a good workaround for anyone that need/want to dev in a newer version of Visual Studio.

@Daniel_L: by the way, is there an equivalent project generation plugin for Eclipse CDT? I can see evidence of it in the source, but I couldn’t find documentation for it anywhere. At the moment, I’ve just been assuming I need to generate my own project templates. I’d love for it to be possible to generate usable CDT projects from gradle as well.

Adding this line to a working build.gradle build script:

apply plugin: 'eclipse-cdt'

…generates this error:

* What went wrong:
A problem occurred evaluating root project 'igc.common.zmq.cpp'.
> Failed to apply plugin [id 'org.gradle.eclipse-cdt']
   > Could not find property 'componentSpecs' on root project 'igc.common.zmq.cpp'.

…is this telling me that eclipse-cdt isn’t a supported plugin at the moment, or that I just need to make some modifications to my build script in order to generate CDT projects?

From this design note would I be correct to infer that the current eclipse-cdt plugin is broken and/or unsupported?

From my knowledge, eclipse-cdt was supported pior to the native support blitz that happen a couple years ago. At that time, native support was extremely trival and was used for jni only. When the full native support, the modeling became much more complex and the plugin just didn’t follow. This could be supported in the future or you can have a look at what needs to be done for that plugin to work again. Post on the dev forum to get the discussion started.

ok - thank you for the background info. I don’t know whether/how much I’ll be able to contribute, but I’ll hop over to the dev forum and see where it goes.