Short Answer:
- make sure EVERYTHING is up to date, clean, restart your IDE
Long Answer, and the reasons why it fails:
This error can have multiple causes (and some can be combined):
1. Some of the projects of your solution aren't updated to the latest version of XF. The problem is then that multiple versions of the Tasks assembly exists, but obviously a single one is loaded by msbuild in the AppDomain, and if it's not the latest one, it fails with the latest .targets file. If you think all of your projects are up-to-date, you can either grep your code to check for references in .csproj, but what I usually do is remove the packages folder, let nuget restore everything, and if I have more than one XF nuget package installed in packages/, that means there's still a reference.
2. restart your IDE. if you update XF, and if the update contains changes in the Tasks assembly, and if that assembly is loaded in the msbuild AppDomain. Reloading your solution should work, but restart your IDE to be sure.
3. cleaning all the bin/ and obj/ is always a good idea too. I do git clean -xfd.
If it still fails
Open an issue on bugzilla with your project, or a valid reproduction, and let me know. I'll look at it. If you have concerns about sharing your code, you can make the bug or the attachment private, and/or discuss NDA with @DavidOrtinau or any Xamarin Customer Support Engineer
I had the same issue so i did the following to resolve
1. Build > Clean All
2. Right click on each project from the solution panel, select Tools then Edit File. This will open the csproj file as text
3. Find all lines with Xamarin and ensure that it use version 2.3.4.247.
4. File > Close Solution
5. File > Close (make sure that Visual Studio is completely shutdown)
6. Open Finder and remove all bin and obj folder from each of your project
7. Open your solution and rebuild
Allow the packages to be restored (automatic on solution-open in VS for Mac)
Observe your packages/ folder. If you see Xamarin.Forms.* folders with more than one version number, then you still have references in your solution (SOMEWHERE) to an older version of Forms.
Use the "Find in Files" feature of VS to search the entire solution folder for the erroneous version number. (In my case it was "2.3.3.152"). You'll probably find instances of that in files like project.json and packages.config.
Delete all references to those erroneous versions of Forms. (You may need some familiarity with packages.config and project.json to this without messing anything up, but it's not too hard.
For safe measure, again Clean the solution, close it, delete bin and obj folders, and delete packages/ folder.
Open the solution again and allow the IDE to restore packages. You should be able to build now.
I was seeing the dreaded The "DebugType" parameter is not supported by the "XamlCTask" task. But now all is well.
I had the same problem, I fixed it by following these steps...
1. Verifying that all of my projects had the same version of Xamarin.Forms. (It turned out that I had updated it in my PCL but not in my iOS project).
2. Close Visual Studio
3. Delete the bin and obj folders for your PCL, iOS, and Android projects
4. Also Delete your packages folder (to get rid of the multiple copies of Xamarin.Forms)
5. Reopen Visual Studio and Build
Deleting the bin/obj folders and restarting vs works, not editing the target files for me. However this bug quickly returns and restarting VS every time is not an ideal solution.
0
JamesMontemagnoUSForum Administrator, Xamarin Team, Developer Group LeaderXamurai
So, this one actually has to do more with NuGet and perhaps not removing and updating the csproj file correctly.
For instance I updated to 2.3.4.247 from an older version and NuGet didn't know how to upgrade and left old busted imports around. Sooo, unload your projects and look into the bottom of all the csproj files for things that aren't correct.
@JamesMontemagno said:
So, this one actually has to do more with NuGet and perhaps not removing and updating the csproj file correctly.
For instance I updated to 2.3.4.247 from an older version and NuGet didn't know how to upgrade and left old busted imports around. Sooo, unload your projects and look into the bottom of all the csproj files for things that aren't correct.
This thread contains a lot of workarounds but no solution:
Restart VS: Yes I it works but if you need a bunch of work done, restarting applications is not very productive
Remove bin and object files: If this is the problem, why didn't do the Xamarin Build tools that for me?
Install the latest Xamarin update. Yes good idea, and multiply your problems with other problems from new updates.
Xamarin drives me frequently crazy, every update has its own specific build problems. There is really never been a Xamarin release that let you run and debug without problems.
Serious guys, this is again a sloppy work of the Xamarin team. Why can't they get this stuff stable. Why don't we all complain a little harder.
My solution: Restart VS and rebuild. Then you have for a short time no problem. But it re-appears soon. And if you want to be busy with starting and closing applications and moving and deleting files it is a great solution. But if you want to deliver, IT DOESN'T HELP A BIT!
Hi, maybe it is an issue with the version of your android's SDK. Taking into account that the latest plugins and libraries are compiled against later APIs I've managed to solve this problem by updating the Android SDK (or downloading) to API 25 and then setting the project's compiler to target that API. Also it's advisable to restart the IDE (VS or Xamarin studio)
Yes, the problem reappears - restarting visual studio and deleting the bin/obj files only fixes it temporarily. The problem ALWAYS comes back. It seems to rear its head if I switch between Local Machine and Remote Machine when debugging UWP.
I only have one Xamarin Forms folder in my packages folder, 2.3.5-pre6.
The UWP csproj file format seems to be different than the iOS and Android. The references are different and it doesn't have the Imports entries.
This issue, combined with Visual Studio locking up because it's "busy" when loading the solution*, is causing a lot of frustration for me today. I'm going to try removing the DebugType parameter from the targets file next.
*To fix this, I have to end the task and delete the .suo file from the v15 folder. Ugh.
Any plans to fix this issue? I'm still getting it and while restarting VS and cleaning the solution is a workaround, its a major pain when you have a large solution that takes a while to open and you're 'mid flow' and dont want to stop to restart becuase of this bug...
For me it was only to select the right project from the Solution Explorer then run.
This error may happen when you have class libraries included in your "solution"
Here's what solved it for me -
- In the Configuration Manager (VS 2017 in the "Debug" drop-down aka Solutions Configuration), I deselected the "Build" check mark for the iOS project.
Keep in mind, I have not yet connected a Mac agent so I have not yet deployed my app to an iPhone Simulator or an iPhone. My guess is that, once I do, I will be able to check the "Build" for the iOS project and will not receive the error.
Still not sure the primary cause of the error, as I see it is happening to various people for various reasons, but we should not have to clean / delete bin & obj / restart VS to solve this problem.
I have updated today from 2.3.4.231 to 2.3.4.270 and for each project in my solution referencing Xamarin.Forms I have build error:
'The "DebugType" parameter is not supported by the "XamlCTask" task. Verify the parameter exists on the task, and it is a settable public instance property.'
I have tried all of your suggestions posted here, that is:
all solution projects references only 2.3.4.270 version (manually deleted packages directory had reverted only 2.3.4.270 Forms version by NuGet)
multiple VS restarting
manually removing all bin and obj folders from all solution projects
Error still persists. Any ideas? I honestly always face different problems when updating to ANY Forms release after 2.3.4.231, which is the last version which works for me.
Xamarin forms is the WORST thing that has ever happened to me in my programming career. I have never had this kind of frustrating issues while trying to work with other frameworks. And for God's sake this is Microsoft, can't anyone just find a lasting solution to this useless beast that .NET has delivered unto us? Starting from simply creating a fresh page whose boiler template crashes. Yet awa Microsoft people are still looking at the useless thing and it has even gotten to the stage where we now have to start checking out blogs on how to fix the BULLSHIT boiler plate that is automatically generated with FOOLISH errors in it. Can't something ever work for God's sake in this thing? Now we have another stupid issue and the only thing they have to say is that we should delete bin and obj folders and reopen visual studio, or edit Xamarin.Forms.Target document, commenting one line of the useless crap that they gave us themselves which is still not a guaranty that the IDIOT would work. Meehn... i would continue to pray that u guys would get it right one day though, but as for me, this is where I depart from this useless .NET MONSTER
@RotimiOdu said:
Xamarin forms is the WORST thing that has ever happened to me in my programming career.....
Odd, Xamarin Forms is one of the best things that has ever happened to me in my programming career. As for frustrating issues, sure it has a few but its all OS so you can take a look inside and see what is happing. Plus the community (yourself excluded) is generally super handy towards each other and to helping the Xamarin team resolve any issues.
Previously, above solutions works for me. But today everything does not work, at the end I solved it by unplugging my Android device from USB port and replug again
This Xamarin excrement is unbelievably bad. Come back DEC - all is forgiven. Your managers may have been completely useless dumb numbskull tarts but at least your hardware and software worked ...
@princepotemkin said:
This Xamarin excrement is unbelievably bad. Come back DEC - all is forgiven. Your managers may have been completely useless dumb numbskull tarts but at least your hardware and software worked ...
This very constructive reply made me realise that it has been quite some time since I did not have problems compiling and/or debugging XF apps, recent versions are waaaaaaaay more reliable than XF used to be, thumbs up.
I was moving some dependencies around, and some of my projects that had been getting a pinned version of Xamarin.Forms ended up getting an older version. Pinning those projects to the version that they had been getting (via a transitive nuget dependency) fixed my issue. Thanks @StephaneDelcroix !
Posts
+1. Thank you, Marco.
Hey guys,
Short Answer:
- make sure EVERYTHING is up to date, clean, restart your IDE
Long Answer, and the reasons why it fails:
This error can have multiple causes (and some can be combined):
1. Some of the projects of your solution aren't updated to the latest version of XF. The problem is then that multiple versions of the Tasks assembly exists, but obviously a single one is loaded by msbuild in the AppDomain, and if it's not the latest one, it fails with the latest
.targetsfile. If you think all of your projects are up-to-date, you can eithergrepyour code to check for references in.csproj, but what I usually do is remove thepackagesfolder, letnugetrestore everything, and if I have more than one XF nuget package installed inpackages/, that means there's still a reference.2. restart your IDE. if you update XF, and if the update contains changes in the Tasks assembly, and if that assembly is loaded in the msbuild AppDomain. Reloading your solution should work, but restart your IDE to be sure.
3. cleaning all the bin/ and obj/ is always a good idea too. I do
git clean -xfd.If it still fails
Open an issue on bugzilla with your project, or a valid reproduction, and let me know. I'll look at it. If you have concerns about sharing your code, you can make the bug or the attachment private, and/or discuss NDA with @DavidOrtinau or any Xamarin Customer Support Engineer
I had the same issue so i did the following to resolve
1. Build > Clean All
2. Right click on each project from the solution panel, select Tools then Edit File. This will open the csproj file as text
3. Find all lines with Xamarin and ensure that it use version 2.3.4.247.
4. File > Close Solution
5. File > Close (make sure that Visual Studio is completely shutdown)
6. Open Finder and remove all bin and obj folder from each of your project
7. Open your solution and rebuild
The most important bit for me was in Stephane's instructions was:
"...if I have more than one XF nuget package installed in
packages/, that means there's still a reference."binandobjfolders in your solution. (If you're on a Mac, you can use this Automator script to add a "Remove bin and obj folders" context action in the OS X Finder: http://www.joesauve.com/remove-obj-and-bin-folders-via-os-x-finder/)packages/folder.packages/folder. If you see Xamarin.Forms.* folders with more than one version number, then you still have references in your solution (SOMEWHERE) to an older version of Forms.project.jsonandpackages.config.packages.configandproject.jsonto this without messing anything up, but it's not too hard.binandobjfolders, and deletepackages/folder.I was seeing the dreaded
The "DebugType" parameter is not supported by the "XamlCTask" task. But now all is well.this is what i did, i guess i'll stay with 2.3.4.231 for a while
I had the same problem, I fixed it by following these steps...
1. Verifying that all of my projects had the same version of Xamarin.Forms. (It turned out that I had updated it in my PCL but not in my iOS project).
2. Close Visual Studio
3. Delete the bin and obj folders for your PCL, iOS, and Android projects
4. Also Delete your packages folder (to get rid of the multiple copies of Xamarin.Forms)
5. Reopen Visual Studio and Build
I did the same thing to my Android project and it worked.
Deleting the bin/obj folders and restarting vs works, not editing the target files for me. However this bug quickly returns and restarting VS every time is not an ideal solution.
So, this one actually has to do more with NuGet and perhaps not removing and updating the csproj file correctly.
For instance I updated to 2.3.4.247 from an older version and NuGet didn't know how to upgrade and left old busted imports around. Sooo, unload your projects and look into the bottom of all the csproj files for things that aren't correct.
For instance I had these two lines:
I removed the old 2.0.1 one from the csproj. I had to close VS and re-open and it worked just fine then.
I have the same problem but no old imports in my csproj files
This thread contains a lot of workarounds but no solution:
Xamarin drives me frequently crazy, every update has its own specific build problems. There is really never been a Xamarin release that let you run and debug without problems.
Serious guys, this is again a sloppy work of the Xamarin team. Why can't they get this stuff stable. Why don't we all complain a little harder.
My solution: Restart VS and rebuild. Then you have for a short time no problem. But it re-appears soon. And if you want to be busy with starting and closing applications and moving and deleting files it is a great solution. But if you want to deliver, IT DOESN'T HELP A BIT!
@TonyMelony it re-appears?! Can you share your project so we can look into that?
Share it on this issue or you could email me directly and we can work something out. [email protected]
https://bugzilla.xamarin.com/show_bug.cgi?id=56640
Hi, maybe it is an issue with the version of your android's SDK. Taking into account that the latest plugins and libraries are compiled against later APIs I've managed to solve this problem by updating the Android SDK (or downloading) to API 25 and then setting the project's compiler to target that API. Also it's advisable to restart the IDE (VS or Xamarin studio)
Hope it helps
Yes, the problem reappears - restarting visual studio and deleting the bin/obj files only fixes it temporarily. The problem ALWAYS comes back. It seems to rear its head if I switch between Local Machine and Remote Machine when debugging UWP.
I only have one Xamarin Forms folder in my packages folder, 2.3.5-pre6.
The UWP csproj file format seems to be different than the iOS and Android. The references are different and it doesn't have the Imports entries.
This issue, combined with Visual Studio locking up because it's "busy" when loading the solution*, is causing a lot of frustration for me today. I'm going to try removing the DebugType parameter from the targets file next.
*To fix this, I have to end the task and delete the .suo file from the v15 folder. Ugh.
Any plans to fix this issue? I'm still getting it and while restarting VS and cleaning the solution is a workaround, its a major pain when you have a large solution that takes a while to open and you're 'mid flow' and dont want to stop to restart becuase of this bug...
This worked for me
Same issue here. Go to "Manage Nuget packages for Solution" and ensure all Xamarin.Forms versions are the same from there - fixed for me
Just upgrading Xamarin.forms from NuGet for Forms, Android and iOS, it works fine
Same here, upgrading all projects to XForms 2.3.4.267 resolve the issue.
I ran into this issue today with a netstandard 1.4 forms project. Cleaning the obj and bin folders resolved the issue.
For me it was only to select the right project from the Solution Explorer then run.
This error may happen when you have class libraries included in your "solution"
Hi all,
Here's what solved it for me -
- In the Configuration Manager (VS 2017 in the "Debug" drop-down aka Solutions Configuration), I deselected the "Build" check mark for the iOS project.
Keep in mind, I have not yet connected a Mac agent so I have not yet deployed my app to an iPhone Simulator or an iPhone. My guess is that, once I do, I will be able to check the "Build" for the iOS project and will not receive the error.
Still not sure the primary cause of the error, as I see it is happening to various people for various reasons, but we should not have to clean / delete bin & obj / restart VS to solve this problem.
Hello
I have updated today from 2.3.4.231 to 2.3.4.270 and for each project in my solution referencing Xamarin.Forms I have build error:
'The "DebugType" parameter is not supported by the "XamlCTask" task. Verify the parameter exists on the task, and it is a settable public instance property.'
I have tried all of your suggestions posted here, that is:
Error still persists. Any ideas? I honestly always face different problems when updating to ANY Forms release after 2.3.4.231, which is the last version which works for me.
Regards
Maciek
Same issue as chetszot. I updated from 247 to 270. It does not help to restart, clean, remove obj/bin.
It works for Android on my PC, but not for iOS on my MacBook...
Edit: Downgraded to 267 and it worked for iOS again.
there is maybe two instance opened of visual studio, and one of them is already in debugging the x application.
Xamarin forms is the WORST thing that has ever happened to me in my programming career. I have never had this kind of frustrating issues while trying to work with other frameworks. And for God's sake this is Microsoft, can't anyone just find a lasting solution to this useless beast that .NET has delivered unto us? Starting from simply creating a fresh page whose boiler template crashes. Yet awa Microsoft people are still looking at the useless thing and it has even gotten to the stage where we now have to start checking out blogs on how to fix the BULLSHIT boiler plate that is automatically generated with FOOLISH errors in it. Can't something ever work for God's sake in this thing? Now we have another stupid issue and the only thing they have to say is that we should delete bin and obj folders and reopen visual studio, or edit Xamarin.Forms.Target document, commenting one line of the useless crap that they gave us themselves which is still not a guaranty that the IDIOT would work. Meehn... i would continue to pray that u guys would get it right one day though, but as for me, this is where I depart from this useless .NET MONSTER
Odd, Xamarin Forms is one of the best things that has ever happened to me in my programming career. As for frustrating issues, sure it has a few but its all OS so you can take a look inside and see what is happing. Plus the community (yourself excluded) is generally super handy towards each other and to helping the Xamarin team resolve any issues.
Maybe the problem isn't forms, maybe its you?
This worked for me.
Previously, above solutions works for me. But today everything does not work, at the end I solved it by unplugging my Android device from USB port and replug again
@ChrisRzepa really really i spent more time to resolve it thanks
جزاك الله كل خير
Setting this up in CI is impossible, don't have the ability to just restart and clean. Keeps messing up in the cloud with the SAME error
Colse visual studio and delete obj and bin for all project(Portable,Android,Ios,UWP)
after open project clean and rebuild.
Its work for me
updating project to use Xamarin.Form v2.5.0.121934 worked for me
For me too
Delete packages and bin, obj for PCL and Droid. open project -> Clean -> Rebuild solution
I ran into this problem after updating to XF 3.
What worked for me was deleting contents of obj folder in both iOS and Android folder and restarting the VS for Mac
This Xamarin excrement is unbelievably bad. Come back DEC - all is forgiven. Your managers may have been completely useless dumb numbskull tarts but at least your hardware and software worked ...
This very constructive reply made me realise that it has been quite some time since I did not have problems compiling and/or debugging XF apps, recent versions are waaaaaaaay more reliable than XF used to be, thumbs up.
Same, and the improvements that came in 3.5 are amazing.
In my case Stephane has it right, as you would expect.
I was moving some dependencies around, and some of my projects that had been getting a pinned version of Xamarin.Forms ended up getting an older version. Pinning those projects to the version that they had been getting (via a transitive nuget dependency) fixed my issue. Thanks @StephaneDelcroix !