Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Go to any Emit (EmitContext) method and try to add
ec.Emit (OpCo // <- No matches here.
It should show at least OpCodes enum from System.Reflection.Emit
Why should there be any ?
System.Reflection.Emit is not used in the headers it's turned off by the STATIC definitition at the top. When removing that from the project options it works.
The comment should be
"It should show at least OpCodes enum from IKVM.Reflection.Emit"
It's a thing with the project model.
Atm wildcard includes aren't supported on IDE level. But we'll fix that.
Another example of wildcard in use (fails to build on MD/Windows):
Fails to build how? Wildcards don't load into the solution tree but if they use the msbuild engine then they should still build.
I would very much like file references with wildcards to load into the solution tree as this would enable me to use MonoDevelop like I use Visual Studio.
This is most useful for cross-platform development when you want to share the same code, but it needs to be built with different project settings and references etc. When not included in the solution tree, it becomes more difficult to make changes to the files. Automatically loading with wildcard would allow MD to pick up new files without having to manually add them to all the different projects.
wildcard is rejected as invalid path name (only on MD for Windows).
Yet I still believe this should not be taken too high priority, very few projects actually use it.
I took a shot at implementing this feature: https://github.com/jaredthirsk/monodevelop
I want this too, for the same reason as Brendon: it makes it much easier for cross-platform development when you have multiple csproj for the same codebase (possibly with per-project defines to activate different #if blocks.) Microsoft has some sort of csproj sync tool that seemed to be hardcoded to help with Silverlight, but it's nicer to avoid that (and I'm not using Silverlight.)
My implementation approach:
At load time, I clone the ProjectFile for each file that matches the wildcard. Hopefully this should capture all the build actions and any attributes.
For the wildcard item itself, I load the ProjectFile into WildcardItems instead of Items, so it doesn't show up in the IDE (or get compiled by users of the Items collection. I looked at how often Items was used and it looked too intimidating to try to stick it in Items and still have everything else work.) I believe these would blow up on Windows as things are now thanks to stricter System.IO.Path.* methods (GetFullPath is called in FileServices when setting the file name on a ProjectFile):
On Windows, System.IO.Path methods (GetFullPath, GetFileName, GetDirectoryName, Combine) will blow up with an ArgumentException when there are *'s in the path. So I rolled my own :-/ and tried to make sure System.IO.Path.* ones are not used while loading a csproj. Somehow, this worked on OS X, I suppose because *'s are valid in filenames on UNIX systems (though obviously not typical).
All I tested was on OS X:
Works! (on OS X at least)
After I rolled my own Path methods, something went wrong with my build and I could no longer compile MonoDevelop on Windows for some reason but the changes still work on OS X. (On Windows 7: NullReferenceException on startup in MonoDevelop.Ide.IdePreferences.get_DefaultTargetRuntime() -- perhaps I am not using the right runtime to match the binary installation when recompiling MonoDevelop.Core.dll, not sure how that works.)
Also I think I botched tabs (spaces still exist in my code) and autoformatting seemed to make it worse (maybe my settings aren't right).
I submitted a pull request, but I'm new so I have no idea how acceptable you think this is as-is.
Thanks, it looks like a good approach. Unfortunately we're overwhelmed with internal deadlines right now so it may be a while until we can review it properly - sorry!
No worries, I know what that's like. For now I'm happy: "worksforme" - hooray for open source.
Is there anything we can do to help bump this issue? It is a huge pain for this to work correctly for all our projects except MonoTouch.
I see James Lupiani has fixed the indentation issue and submitted a new pull request. Thanks.
I am still looking forward to this as well, as compiling MonoDevelop is complicated and I have resorted to creating a tool that generates XML snippet that I manually copy and paste into the other csproj file when I need to sync two projects.
This should be a more important issue given that there are more and more developers making multiplatform games with multiplatform code using MonoGame with MonoTouch/MonoAndroid and since plenty of those developers are individuals, they can't afford buying Visual Studio Professional, making it impossible to use Xamarin tools with VS. And, for these developers, wildcards are the most convenient way to include code from other projects.
Unity3D developers are another group of users to add to Martin's list.
(Me: I am a Unity3D & MonoTouch user who can't afford VS Pro yet although I may try BizSpark. As an aside, I also use the main MonoDevelop on OSX, or Visual Studio 2012 Express to build most of my DLLs instead of Unity's older customized MonoDevelop.)
(And thanks for upgrading the priority, Micheal.)
Lluis landed the pull request.
I noticed the latest update (4.0.5 - build 4) states it includes this.
I have updated and tried switching a Xamarin.Android project to use:
<Compile Include="Source\**\*.cs" />
This is the syntax I have been using for Visual Studio, but the .csproj no longer loads into Xamarin Studio (the error is: "illegal characters in path").
Is this the correct syntax or am I missing something?
To re-visit what others have said here:
I'm an indie games developer porting a game from Windows Phone to Android, iOS and various others using MonoGame. Once I have the code separated out, the most time consuming thing I have to do when I make updates is going through the different projects and making sure I have added the correct files to each one in turn. This isn't a huge deal for code files, but we also have to use the same process to add content files. Any of these that are missed can be a huge issue as no build error will be thrown and it can take a lot of testing to find a missing resource.
I guess this was only tested on Mac, where * is a valid path character. I tested this on Windows and looked at the logs, and the problem is the Path.GetFullPath call in MSBuildProjectService.FromMSBuildPath.
Fixed in master.
This bug was re-introduced with the most recent release.
Confirmed for OSX/Xamarin
(Not confirmed on Windows)
=== Xamarin Studio ===
Version 5.8 (build 443)
Installation UUID: e3a17395-8563-42a7-879f-ad58190c4714
Mono 3.12.1 ((detached/b7764aa)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312010000
=== Xamarin.Android ===
Version: 22.214.171.124 (Starter Edition)
Android SDK: /Users/charlesstrong/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0.3 (API level 15)
4.4 (API level 19)
Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
=== Xamarin Android Player ===
=== Apple Developer Tools ===
Xcode 6.2 (6776)
=== Xamarin.iOS ===
Version: 126.96.36.199 (Starter Edition)
Build date: 2015-03-10 02:20:32-0400
=== Xamarin.Mac ===
=== Build Information ===
Release ID: 508000443
Git revision: 73883239470cbe8e261c94d95f7c3d0452fd393b
Build date: 2015-03-10 07:22:51-04
Xamarin addins: a2ff7b617f09d9c45d8bbf3d010b5db0d7d36100
=== Operating System ===
Mac OS X 10.10.2
Darwin <SCRUBBED for SECURITY> 14.1.0 Darwin Kernel Version 14.1.0
Thu Feb 26 19:26:47 PST 2015
Down-grading to 5.7.2 did not resolve the issue. It may have been introduced in a prior release.
I can verify this issue exists in all releases of Xamarin for OSX available at
example failing wild-card path
<Content Include="Content\**\*.*" />
Fixed in version 188.8.131.528 (new-project-model)
I have checked this issue with latest Roslyn XS i.e
I have made following changes in my project file:
<Compile Include="..\abh-add\**\*.cs" />
<Compile Include="..\abh-add\**\*.*" />
My project is build successfully.
Could you please have a look to my screencast and let me know If I need to check anything else to verify this issue.