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 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.
Since the latest beta update (3.6.something) of 11th sept. Visual Studio 2013 U3 won't open PCL projects anymore, at least most of them.
It'd say "The project is incompatible with the current edition of Visual Studio" in solution explorer.
Repro: Create a new solution with a PCL class library, i.e. Profile7. Everything is fine. Save and reopen - bum won't load it.
It's the alpha version
For me it is beta as I am on beta channel. Or did alpha infiltrate beta channel somehow?
it has been moved to beta also this morning :)
Same problem, Profile78
I have tried to reproduced this issue and I am also getting the same issue. When I create PCL project save it and reopen it again then it shows message "The project is incompatible with the current edition of Visual Studio" in solution explorer for Library project.
IDE Log: https://gist.github.com/sunil360/f1d95e414da307330c5f
VS 2013 update 2
Xamarin 22.214.171.124 (9a4fd01eaf32adf894f8bd1d687455dcb905f427)
Xamarin.Android 126.96.36.199 (62e09eb09d3a9056653f1ef497de30b53bf04f47)
Xamarin.iOS 188.8.131.52 (1ed3187e662f3b5a059fa6df4d7c480046290ea3)
We're already looking into this issue.
The root cause of the issue is that we were using the same DisplayName for both: Xamarin.iOS.xml and Xamarin.iOS.Unified.xml in every portable profile.
i.e. You can see this case in "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile78\SupportedFrameworks" where both xml files are using the same DisplayName="Xamarin.iOS". This was making VS to mixup the referenced assemblies and failing to load the project with an "Incompatible" error.
The manual workaround is to replace the Xamarin.iOS.xml DisplayName="Xamarin.iOS (Classic)", at least in the profile you're using, but you might need to do that change for every profile.
We already have a fix, which should be available soon.
@Jose I've updated the Xamarin.iOS.xml files (for all profiles) and I'm still seeing the same issue?
It fixes the issue for me
Make sure you're using .net 4.5 ?
Ok it fixes this issue, but it still have a show stopper issue (compilation error) when implemeting an interface containing a generic type.
oups no sorry it didn't fixed it.
I am using .NET 4.5
fix doesn't work for me either
I works when you remove all xamarin.ios.unified.xml files. But then you can no more reference a PCL project from an ios project.
Unless you have done so before.
Ok it works but ios projects won't compile. It does not find generics used by methods in a C# interfaces from PCL.
Ok i managed to get it work. Here's how:
go to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\
search and delete all files called "Xamarin.iOS.xml"
Restart Visual Studio
It fixes all issues EXCEPT my bug 22812 (can not implement an interface declared in a PCL if the interface contains method with a generic parameter: won't compile).
Created attachment 8026 [details]
@Softlion: Removing all Xamarin.iOS.Unified.xml files from the Profiles means we're not longer compatible with those profiles. Hence it makes sense you cannot reference PCLs anymore, or if you already have some referenced, your project doesn't build.
@Jamie, @krahenbuhl: I also had to restart Visual Studio, and my changes were in all the profiles (for v4.0,v4.5 and v.4.6). This will be done by our installer once the fixed version is public.
This is how I implemented the workaround in my machine:
1. Close all Visual Studio instances.
2. Move all the Profile folders you don't use to a Backup folder (so you can restore it later), I recommend you to group them by .Net version (v4.0, v.4.5 and v4.6). Leave just the ones you use, like i.e. v.4.5/Profile78
3. Replace Xamarin.iOS.xml in the remaining profiles (i.e.Profile78) with the attached one (In comment 20).
That said, We'll investigate the build error to see if there is anything else needed.
We have checked this issue and now this does not exist. When I create PCL project, save and close it and reopen it again then it reloads successfully.
Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Xamarin 184.108.40.206 (b0fc63894f19ecfc80ad83f515319a6348fc605a)
We are getting error on creating PCL project and I have field Bug 22938 for the same.
Hence I am closing this issue.
@Jose thanks. I only replaced the .NET 4.5 files - there's many more files in .NET 4!
Now I have errors about attributes in the PCLs not being attributes and missing references to System.ObjectModel and System.Runtime...
A quick update, to clarify the current status: There are actually two issues in the Alpha/Beta 3.6.197 versions related to this scenario:
1) PCL projects cannot be open (This one is fixed, and soon will be public, this is the fix + workaround mentioned on this thread).
2) Build errors due to missing references on PCLs (this is a different issue, and cannot be seen until you can actually reload the PCL). This issue is currently under investigation.
We'll post here updates about the progress on the second issue.
We found what's causing the second issue. It was the iOS Build targets file that was not including facade assemblies in the build process. The workaround is to patch the target file, typically located on:
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets
You can close Visual Studio, copy that file into a different location, edit it replacing the "ResolveReferenceDependsOn" element with the following:
and then copying it back replacing the one in the MSBuild\Xamarin\iOS folder.
That should avoid the missing references error.
We'll continue working on the official fix for this second issue which should be available soon.
Thanks @Jose, builds and deploys now (although doesn't debug) :-)
It fixed the referencing errors I had before, and deploys and runs on the simulator but now this is present when deploying / building for the device:
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(384,3): warning : The dependency 'System.Threading.Tasks, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' of the assembly 'Core, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null' was not found. Please review the project's references.
Thanks Jose - the two workarounds work fine for me
Actually it works fine for existing projects however, when updating nuget packages the errors reoccurs (for example after updating Xamarin.Forms -> the old version is removed but new version cannot be installed - it works if they are changed manually in the .csproj file).
this is NOT fixed in 22.214.171.124.
The reference errors is still there. If the fix is applied and the solution reopened, all ios projects displayed are "incompatible" and an error is displayed.
<description>SetSite failed for package [MonoTouchPackage]</description>
<errorinfo>Activation error occured while trying to get instance of type IBuildHost, key ""</errorinfo>
To fix, i deleted all Xamarin.iOS.Unified.xml files in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5
Well no, that fix it one time only.
softlion: It works for me - the latest update fixed the Xamarin.iOS files, no need to touch them anymore.
I still had the unrelated reference bug for which the fix is editing:
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets
You can close Visual Studio, copy that file into a different location, edit it
replacing the "ResolveReferenceDependsOn" element with the following:
Hope it helps
The NuGet team has released an alpha version of 2.8.3 which includes support for the new Xamarin.iOS.Unified profile: https://nuget.codeplex.com/releases/view/133091
This should resolve error messages about:
- Cannot install a Nuget Package on any of the compatible Portable Class Library profiles
- Create a Xamarin.Forms application or library shows a NuGet Package error
This avoids needing to remove all of the Xamarin.iOS.Unified.xml files.
@greg: version 126.96.36.199 has all fixes, but all Android/ios projects fail to load. Going back to stable.
Removing the Xamarin.iOS.Unified.xml files seems to fix the issue only once.
New profile xml files are created when upgrading Xamarin to a newer version. After upgrading to Xamarin to 3.9.344.0, the Xamarin.iOS.Unified.xml files are created with still contain the display name that cause the PCL loading problem:
<Framework DisplayName="Xamarin.iOS" Identifier="Xamarin.iOS" Profile="*" MinimumVersion="1.0" MaximumVersion="*" />
When will there be a permanent fix for this bug?
The issue you're facing sounds like an old NuGet Packaged Manager in Visual Studio.
According to Xamarin VS 3.9 Release Notes (http://developer.xamarin.com/releases/vs/xamarin.vs_3/xamarin.vs_3.9/):
Update to latest NuGet Package Manager (2.8.3+) is required
Updating to the latest version of Microsoft NuGet Package Manager, which is compatible with Xamarin.iOS Unified API, is required. It can be updated from the Visual Studio Extension Manager.
More information is available in the following Visual Studio Gallery's links:
VS 2013: https://visualstudiogallery.msdn.microsoft.com/4ec1526c-4a8c-4a84-b702-b21a8f5293ca
VS 2010, VS 2012: https://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c
Hope that helps!
Forgot to mention that I did upgrade NuGet to v2.8.3 after upgrading Xamarin to v3.9. After upgrading NuGet restarting VS2013 my PCL's did not load.
Anyhow, I cannot understand why Xamarin did not fix the root cause, that is changing the DisplayName in the XML file.
The display name issue was fixed months ago. I'll verify it just in case it's a regression, and confirm.
Perhaps you still have the old xmls for some reason?
I'll comment once I can confirm.
Thanks for the clarification!
I can confirm the fix stills in place, and the Xamarin.iOS.Unified.xml and Xamarin.iOS.xml files we ship do have the right DisplayName.
For instance, after installing the latest stable (v3.9.344), Xamarin.iOS.xml contains:
<Framework DisplayName="Xamarin.iOS (Classic)" Identifier="MonoTouch" Profile="*" MinimumVersion="1.0" MaximumVersion="*" />
This might be some setup issue on your machine or in the installer itself.
Please try installing the msi from this URL http://download.xamarin.com/XamarinforVisualStudio/Windows/Xamarin.VisualStudio_3.9.344.msi which should match the current stable, and let me know if you continue seeing the wrong DisplayName.
Also, the full path of the xml file you're seeing the issue would also help, as if it's wrong just in some of the profiles but it's good in the other profiles.
Thanks Jose for confirming this. I checked the xml files on my system and can explain exactly what the problem is with my Xamarin installation.
The installer of version 3.9.344 did, in my case, not overwrite existing Xamarin.iOS.xml files with the fix. New Xamarin.iOS.Unified.xml files were created correctly during install (because these files did not exist).
So there seems to be an issue with overwriting the xml profiles. I suspect this is not related to fs write permissions because new xml files were created correctly.
In addition, i can inform you that sub folders of these folders still contain old xml files after the upgrade:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile[nr]\SupportedFrameworks
Closing since the error isn't happening anymore.