Error 1 Unexpected error - Please file a bug report at http://bugzilla.xamarin.com. Reason: System.IO.DirectoryNotFoundException: Directory 'D:\Mir\─░┼ƒ\Projects\foldername\projectname\bin\Debug' not found. Projectname
Project: API Level 10
Mono.Android reference Runtime Version: v2.0.50727
Error occurs during debug process.
─░┼ƒ in the error message stands for the folder name with 2 Turkish chars: İş
I've changed the folder's name to one which isn't with turkish chars and now the error is gone.
We have checked this issue and we are able to reproduce this issue
Steps to reproduce this issue:
(1) Create a folder with the name of "İş" (it is a turkish word which means business)
(2) Create an android application within the above created folder.
(3) Debug the "android application".
We observed that when we follow the above steps and debug our application it create an new folder with the name i.e. "Ä°ÅŸ" on the same location where we have our "İş" directory. Which contain "debug" folder inside "obj" directory.
We also observed that when we changed the folder name with english character our application is building and deploying successfully.
We also checked this issue on mac machine and follow the above steps and we are getting following error on mac machine.
" error: error while writing <anonymous ytytyt.ytytyt.TrialSplashScreen$1>: obj/Debug/android/bin/classes/ytytyt/ytytyt/TrialSplashScreen$1.class (No such file or directory)"
Version 4.2.3 (build 60)
Installation UUID: 851620d2-e950-4682-b459-991ccec9d895
Microsoft .NET 4.0.30319.18408
GTK+ 2.24.22 theme: MS-Windows
Version: 4.12.2 (Enterprise Edition)
Android SDK: D:\SDK\AndroidSDK
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: C:\Program Files (x86)\Java\jdk1.6.0_31
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
Release ID: 402030060
Build date: 2014-03-05 16:53:54Z
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044
Windows 6.1.7601.65536 (64-bit)
This bug is "funny," and by "funny" I mean "interesting," and by "interesting" I mean I want to crawl into a hole.
First, because nobody asked, what happens on OS X?
Funny you should ask; it depends on how you build! If you build and install from Xamarin Studio, it doesn't work:
> E/mono (31164): Android.Content.Res.Resources+NotFoundException: Exception of type 'Android.Content.Res.Resources+NotFoundException' was thrown.
If you build and install with `xbuild /t:Install` (via Terminal.app), it works. The major difference between them? The xbuild output contains obj/**/R.java; the XS output does not.
These issues are probably unrelated to the Windows issues.
Returning to Windows, here's an interesting aside: The `android` program is able to create "stub" Java projects:
$ android create project -t TARGET -p PATH -k PACKAGE -a ACTIVITY
Note: `-t TARGET` must be an id value that `android list target` provides.
So how's the Android SDK act?
# OS X
$ mkdir İş
$ cd İş
$ android create project -t 10 -p scratch.turkish_dir.j -k scratch.turkish_dir.j -a MainActivity
> Created project directory: scratch.turkish_dir.j
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/src/scratch/turkish_dir/j
> Added file scratch.turkish_dir.j/src/scratch/turkish_dir/j/MainActivity.java
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/bin
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/libs
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/values
> Added file scratch.turkish_dir.j/res/values/strings.xml
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/layout
> Added file scratch.turkish_dir.j/res/layout/main.xml
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/drawable-xhdpi
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/drawable-hdpi
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/drawable-mdpi
> Created directory /Users/jon/Downloads/bxc-18897/??/scratch.turkish_dir.j/res/drawable-ldpi
> Added file scratch.turkish_dir.j/AndroidManifest.xml
> Added file scratch.turkish_dir.j/build.xml
> Added file scratch.turkish_dir.j/proguard-project.txt
Notice all the "??" directory names? That's supposed to be "İş".
However, `ant` still manages to build:
$ cd scratch.turkish_dir.j
$ ant debug
So that's the OS X side of things. Windows?
> mkdir İş
> "%LOCALAPPDATA%\Android\android-sdk\tools\android.bat" create project -t 6 -p scratch.turkish_dir.j -k scratch.turkish_dir.j -a MainActivity
Error: The working directory does not seem to be valid: 'C:\Users\jonp\Documents\bxc-18897\Is\Is
That's not at all encouraging. :-/
Android SDK aside, even if I create a Xamarin.Android project on Windows within a directory containing "İş", it won't build:
> obj\Debug\android\AndroidManifest.xml(6): error :
> No resource found that matches the given name (at 'icon' with value '@drawable/icon').
> [C:\Users\Jonathan Pryor\Documents\bxc-18897\Is\Scratch.TurkishDirWin\Scratch.TurkishDirWin\Scratch.TurkishDirWin.csproj
Apparently `aapt` can't find the (present) obj/Debug/res/drawable/icon.png file.
I do wonder why I'm the only one to get a build error on Windows. Very odd. :-/
Returning to Comment #2:
> We observed that when we follow the above steps and debug our application it
> create an new folder with the name i.e. "Ä°ÅŸ"
I too see the directory:
Investigation of the source code suggests that there are only two places that would create the __library_projects__ directory:
1. The <GetExtraPackages/> task, and
2. The <ResolveLibraryProjectImports/> task.
The <GetExtraPackages/> task doesn't create the directory, so that can't be it, leaving the <ResolveLibraryProjectImports/> task, which could, except I don't see how/why this would create it.
This looks closely related to bug 14918.
Consequently it might be most accurate to classify this bug as an enhancement.