Bug 7556 - Solution 'platform' definitions not respected
Summary: Solution 'platform' definitions not respected
Status: NEW
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: C Binding ()
Version: 2.8.6
Hardware: PC Linux
: Lowest normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-09-30 18:09 UTC by Manu
Modified: 2013-08-21 00:31 UTC (History)
2 users (show)

Tags: mono-community
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 7556 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Manu 2012-09-30 18:09:59 UTC
The platforms created in the .sln file are not recognised/supported by the C/C++ .cproj files.

The configurations ONLY work when mapping to the .sln configurations to a magic 'Any CPU' platform, and projects in the .cproj to another magic 'AnyCPU' platform. (Strangely, the 2 aren't even identical platform names, one with and without a space)

It would seem MonoDevelop C/C++ performs a fair amount of magic with regard to project platforms.
Is it possible to fix it such that multiple platforms will work like Visual Studio? (x86 & x64 in same solution for instance)
Comment 1 Mikayla Hutchinson [MSFT] 2012-10-01 16:43:17 UTC
The C/C++ addin isn't architecture aware at the moment, but that shouldn't be a problem.

Platforms don't work that way - the "platform" in the solution and project are really just a part of the configuration name, and don't (usually) have any special behaviours built in. The behaviours are caused by the configuration values.

 I'm pretty sure you could create x86 and x64 solution configurations, map them to matching project configurations, then use the "additional compiler arguments" in the configuration to set the compiler's platform.
Comment 2 Manu 2012-10-02 03:41:13 UTC
Well, that leads me to a secondary question. Why support .sln platforms at all?
Is there a reason there is no second selectbox to choose the platform beside the configuration?

My problems arise when I have an established build system. It feels rather sloppy to produce configurations*platforms different configurations to support multiple platforms. .sln expressed the concept of platforms to mitigate this nastiness. Is VisualStudio style platform selection currently possible? And if not, is it a lot of work?
Comment 3 Mikayla Hutchinson [MSFT] 2012-10-02 12:52:46 UTC
Platforms in VS work exactly the same as they do in MD, just look at the sln file and you'll see all the definitions. The only difference is the UI.
Comment 4 Manu 2012-10-02 13:13:13 UTC
Oh I think I see what you mean, there's only one drop-box with all 'Config|Platform' entries in it? In my case, that box may exceed the vertical screen real estate, I'd prefer 2 separate boxes, but that's not an issue here ;)

But yeah, so the situation is, MonoDevelop does understand platforms, but the C/C++ plugin does not. I'll have a look at the code, and see if I can realistically participate.
Is the C/C++ extension code maintained separately/externally?
Comment 5 Mikayla Hutchinson [MSFT] 2012-10-02 13:30:48 UTC
Yes, it's quite likely that in future versions of MD we will split the comboboxes.

The C binding is in the MonoDevelop GitHub repository, part of the main MD solution: https://github.com/mono/monodevelop/blob/master/main/src/addins/CBinding/CBinding.csproj

You can fork the repo, make changes if your copy, and submit them as pull requests against the main repo.

You may find the following pages useful:
Comment 6 Manu 2012-10-02 16:01:55 UTC
I'll check it out. Thanks!
(I just noticed, I think the D plugin also suffers the same problem... >_<)
Comment 7 Manu 2012-10-06 08:58:34 UTC
Assembly 'Mono.Addins, Version=, Culture=neutral, PublicKeyToken=0738eb9f132ed756' not found. Make sure that the assembly exists in disk. If the reference is required to build the project you may get compilation errors.
Assembly 'Mono.Addins.Setup, Version=, Culture=neutral, PublicKeyToken=0738eb9f132ed756' not found. Make sure that the assembly exists in disk. If the reference is required to build the project you may get compilation errors.

I seem to be missing these 2 assemblies: Mono.Addins, Mono.Addins.Setup
The build instructions page say to install 'Mono.Addins 0.5', but I can't find any package that seems to provide that. There are a bunch of libmono-addins-.... packages, I installed all of those, but they don't seem to be correct.

I'm running Mint13, which should have all the Ubuntu packages available.
What have I missed? >_<
Comment 8 Manu 2012-10-20 08:35:35 UTC
Any help anyone? I really want to do some work on the C/C++ integration.
Comment 9 Mikayla Hutchinson [MSFT] 2012-10-22 15:59:10 UTC
Try again with an updated checkout - since a few days ago MD master includes mono-addins as a submodule, instead of expecting it to be installed on the system.