With Version 3.5.x of Xamarin Forms I have a lot of errors all regarding the Resource.Designer in the obj-Debug-[Version]-designtime folder.
I experimented around with the target and minimum Android SDK Version but had it with both 9.0 and 8.1.
(since I was no able to get the errors in an output, I add a Screenshot here)

It seems that this is caused by entries like:
// aapt resource value: 0x7F010174
public const int bottomtab.navarea = 2130772340;
// aapt resource value: 0x7F010175
public const int bottomtab.tabbar = 2130772341;
Also these do not exist in the Resource.Designer used to build the app.
I tried deleting all the bin and obj folders, but the file is always regenerated with the same entries.
Open a solution in either VS 2019 or 2017 with Xamarin Forms >= 3.5 in the project.
No Errors.
Error messages appear.
I was able to reproduce some resolution issues when loading this project "untouched" in VS2017/2019, but deleting the included bin and obj folders and allowing a fresh NuGet restore to complete did put me back in a working state. There seems to be a potential bin/obj and NuGet related issue that could be investigated further using the attached project. However, I didn't encounter any Resource.designer.cs related errors after changing target framework versions or playing around with this project in VS2017 and VS2019.
@pjcollins Thanks for your feedback. Have you restartet VS after you where able to build? What I observed is the Designer file recreated on a restart.
I think I can reproduce it command-line (I deleted bin/obj directories first):
# Build the netstandard project
> msbuild .\App1\App1\App1.csproj /restore
# Simulate a design-time build that would happen in the IDE
> msbuild .\App1\App1.Android\App1.Android.csproj /restore /t:Compile /p:DesignTimeBuild=True /p:BuildingInsideVisualStudio=True
This was VS 2019 GA.
Got a bunch of errors like:
obj\Debug\81\designtime\Resource.designer.cs(5048,21,5048,30): error CS0145: A const field requires a value to be provided [C:\Users\jopepper\Downloads\App1 (5)\App1\App1\App1.Android\App1.Android.csproj]
obj\Debug\81\designtime\Resource.designer.cs(5048,30,5048,31): error CS1003: Syntax error, ',' expected [C:\Users\jopepper\Downloads\App1 (5)\App1\App1\App1.Android\App1.Android.csproj]
obj\Debug\81\designtime\Resource.designer.cs(5048,31,5048,38): error CS1002: ; expected [C:\Users\jopepper\Downloads\App1 (5)\App1\App1\App1.Android\App1.Android.csproj]
Will see if this happens with xamarin-android/master.
So it looks like master is working, but with _lots_ of warnings:
# There were ~2,000 of these!
Xamarin.Android.Common.targets(1332,2): warning XA0106: Skipping App1.Droid.Resource.Styleable.ViewStubCompat_android_layout. Please check that your Nuget Package versions are compatible.
I need to figure out where the problem is here, it seems we have duplicate resources in some of the support library NuGets?
It looks like the problem with the C# compiler error was fixed in: https://github.com/xamarin/xamarin-android/commit/752a25f3a04039d59f52c5c9e3e02ccabd80b08c Duplicates are now warnings, why are there so many?
@jonathanpeppers This issue is also reported on other places, see:
https://stackoverflow.com/questions/55137449/xamarin-forms-generates-wrong-ressources
This looks related to this change https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.Android/Resources/Layout/BottomTabLayout.axml#L13.
Xamarin.Forms is using android:id="@+id/bottomtab.tabbar". It seems the ManagedResourceParser is NOT fixing up android id values with contain a ..
It should be producing public const int toolbar_one = 2131230899; not public const int toolbar.one = 2131230899;
There might be a way to work around this but it will come at a design time build performance cost. You can set the AndroidUseManagedDesignTimeResourceGenerator to False in your csproj. This will mean the design time build will fall back on the old aapt based generator (which is slower), but it should work.
Place the following in the first PropertyGroup if the Android csproj.
<AndroidUseManagedDesignTimeResourceGenerator>False</AndroidUseManagedDesignTimeResourceGenerator>
@dellis1972 Seems to solve the issue but what did you mean with this?
it will come at a design time build performance cost
Do you mean the very aweful Xamarin.Forms Previewer? Or the Android native "designer" which is also average at best?
The Design Time Build is what Visual Studio does in the background to generate code completion and intellisense. Normally this build should run very quickly, this is one of the reasons the ManagedResourceParser exists. Aapt however can be very slow, especially on projects with allot of resources. So disabling the ManagedResourceParser might mean the IDE becomes a bit sluggish when a Design Time Build is running, this is normally when you save a axml layout file you are working on.
I'm working on a fix for the ManagedResourceParser now.
Just a heads up I'm still seeing this issue on the latest version of VS2019 4.7.03190
Deleting the Resource Designer fixes temporarily, then rebuilding brings it right back.
@aherrick you will still see it in the stable release since we just merged this into master, and cherry-picked it to d16-2 (which is the next preview).
@dellis1972 thanks for the update... will keep an eye out.
FYI this still isn't fixed. VS 2019 16.1.0
@aherrick the fix was cherry-picked to the 16.2 branch , it should be in Preview 2. I don't think we can back port this to 16.1 . Note the work around for 16.1 is to add
<AndroidUseManagedDesignTimeResourceGenerator>False</AndroidUseManagedDesignTimeResourceGenerator>
to your csproj PropertyGroup
Thanks! The work around solved this for me.
Can this fix be released for S 2017 as well?
as said above by @jgold6 , it's very important support vs2017!
@jgold6 @candidodmv does the work around not work for VS2017?
The work around does work for VS 2017. As such I have already been informed by @bholmes that the fix for this will not be backported to VS 2017.
I have 3 computers with the same setup and this only happens on one machine. Anybody knows why? I have to fix it with the workaround but wonder whats different to the other installations. They are totally same, even packages, updates.
I am facing this issue still exists in latest VS 2019 version. and works with work around changes in project file.
Is this issue addressed already as it is in closed state now?
Tx
@dev-thinks The fix was shipped, you might have hit a different corner case. Can you open a new issue and attach a repo project and/or diagnostic build logs so we can investigate.