Bug 93 - [patch] MD doesn't support filename wildcards in project files
Summary: [patch] MD doesn't support filename wildcards in project files
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: Trunk
Hardware: PC Linux
: High major
Target Milestone: Roslyn
Assignee: Lluis Sanchez
Depends on:
Reported: 2011-07-27 14:48 UTC by Marek Safar
Modified: 2015-11-27 09:25 UTC (History)
13 users (show)

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 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.

Related Links:

Description Marek Safar 2011-07-27 14:48:36 UTC
Open /mono/mcs/mcs/mcs.csproj

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
Comment 1 Mike Krüger 2011-09-28 03:55:06 UTC
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.
Comment 2 Marek Safar 2011-09-28 04:15:21 UTC
The comment should be

"It should show at least OpCodes enum from IKVM.Reflection.Emit"
Comment 3 Mike Krüger 2011-09-28 04:53:17 UTC
It's a thing with the project model.

Atm wildcard includes aren't supported on IDE level. But we'll fix that.
Comment 4 Atsushi Eno 2012-06-11 03:58:22 UTC
Another example of wildcard in use (fails to build on MD/Windows):
Comment 5 Mikayla Hutchinson [MSFT] 2012-06-11 20:13:35 UTC
Fails to build how? Wildcards don't load into the solution tree but if they use the msbuild engine then they should still build.
Comment 6 Brendon Duncan 2012-06-14 20:35:04 UTC
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.
Comment 7 Atsushi Eno 2012-06-14 21:20:00 UTC
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.
Comment 8 Jared Thirsk 2012-09-20 09:13:14 UTC
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).  

My testing:
All I tested was on OS X: 
<Compile Include="**\*.cs"/>
<Compile Include=".\**\*.cs"/>

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.
Comment 9 Mikayla Hutchinson [MSFT] 2012-09-21 19:35:54 UTC
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!
Comment 10 Jared Thirsk 2012-10-03 02:48:32 UTC
No worries, I know what that's like.  For now I'm happy: "worksforme" - hooray for open source.
Comment 11 Tom Spilman 2013-02-12 22:59:47 UTC
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.
Comment 12 Jared Thirsk 2013-02-15 15:26:27 UTC
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.
Comment 13 Martin 2013-02-26 09:30:35 UTC
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.
Comment 14 Jared Thirsk 2013-02-28 02:27:56 UTC
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.)
Comment 15 Miguel de Icaza [MSFT] 2013-03-11 11:14:09 UTC
updating priority
Comment 16 Mikayla Hutchinson [MSFT] 2013-03-11 16:46:49 UTC
Lluis landed the pull request.
Comment 17 croberts 2013-05-13 12:37:52 UTC
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.
Comment 18 Mikayla Hutchinson [MSFT] 2013-05-13 15:28:18 UTC
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.
Comment 19 Lluis Sanchez 2013-06-04 09:34:02 UTC
Fixed in master.
Comment 20 Charles 2015-03-24 13:42:26 UTC
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: (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 ===

Not Installed

=== Apple Developer Tools ===

Xcode 6.2 (6776)
Build 6C131e

=== Xamarin.iOS ===

Version: (Starter Edition)
Hash: ccfcd59
Build date: 2015-03-10 02:20:32-0400

=== Xamarin.Mac ===

Not Installed

=== 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
    root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64
Comment 21 Charles 2015-03-24 13:54:39 UTC
Down-grading to 5.7.2 did not resolve the issue. It may have been introduced in a prior release.
Comment 22 Charles 2015-03-24 14:07:56 UTC
I can verify this issue exists in all releases of Xamarin for OSX available at 




example failing wild-card path

<Content Include="Content\**\*.*" />
Comment 23 xamarin-release-manager 2015-04-08 07:07:21 UTC
Fixed in version (new-project-model)
Comment 24 Atin 2015-11-27 09:25:42 UTC
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.

Screencast: http://www.screencast.com/t/HkV2gIRGA

Could you please have a look to my screencast and let me know If I need to check anything else to verify this issue.