"Remove Unused References" issue

[pfafft33]

Description

When I right-click on my main shared-code project and select "Remove Unused References", it tells me to remove Xamarin.Forms, which seems very strange to me since this is the project with all of the XAML pages defined.
What is even stranger is that if I go ahead and tell it to remove Xamarin.Forms from the project, the solution still compiles and runs OK.
Can somebody please explain this behavior to me? It seems like it is a bug.

Steps to Reproduce

Expected Behavior

I expect the IDE to throw errors when I remove Xamarin.Forms reference from my main shared-code project.
I have using statements for BOTH Xamarin.Forms and Xamarin.Forms.Xaml in the App.xaml.cs file.

Actual Behavior

The actual behavior is that the solution builds and runs OK, WITHOUT Xamarin.Forms reference in the main shared-code project.

Basic Information

• Version with issue: 16.11.0
• Last known good version:
• Platform Target Frameworks:
  • iOS:
  • Android:
  • UWP:
• Android Support Library / AndroidX Version:
• NuGet Packages:
• Affected Devices:

Environment

Show/Hide Visual Studio info

Build Logs

Screenshots

Reproduction Link

Workaround

[ahoke-cr]

A reference to the Xamarin.Forms namespace is only required if you're directly referencing objects directly in that namespace.

Some examples of types under Xamarin.Forms include:

• Color
• Any view (Entry, Picker, StackLayout, Label, etc.)
• Command
• Any Page (NavigationPage, ContentPage, etc.)

If your shared-code project only houses business logic that is not concerned with the UI, then it would be sensible for that project not to reference Xamarin.Forms.

[pfafft33]

Thanks for the response.
However, if I'm understanding correctly, my shared-code project still needs to reference Xamarin.Forms because the ViewModels are in that project, and almost every ViewModel uses the "Command" type.

[ahoke-cr]

Have you added any other NuGet packages that provide an ICommand implementation? If you have unused references to Xamarin.Forms in a ViewModel that uses the Xamarin.Forms.Command type then I think this would be a bug, though I'm not sure if it's a Xamarin bug or a Visual Studio analyzer bug.

[pfafft33]

I have the following NuGet packages listed under package dependencies for the shared-code project:

• ImageFromXamarinUI
• MailKit
• NETStandardLibrary
• Plugin.InAppBilling
• Xamarin.CommunityToolkit
• Xamarin.Essentials

I'm not sure if any of these have an ICommand implementation.
What's the quickest way to discover if they do?

[ahoke-cr]

If you hover over the type of a variable declaration the tool tip will tell you the namespace the type is coming from. Xamarin Community Toolkit does provide an AsyncCommand implementation, but I don't think any of the others listed provide a "Command" implementation.

[pfafft33]

When I hover over ICommand I see:
interface System.Windows.Input.ICommand

When I hover over Command I see:
Command.Command(System.Action execute) (+1 overload)

[ahoke-cr]

Right. If you go to definition on the new Command(...) instantiation it should show you the definition with namespace at the top from metadata.

[pfafft33]

When I go to "Definition" on the Command(. . .) I see at the top:
namespace Xamarin.Forms

I also still have, at the top of my ViewModel:
using Xamarin.Forms;

and this using statement is NOT getting flagged with any errors, even though I have removed the Xamarin.Forms NuGet package from the shared-code project.

[ahoke-cr]

That's very strange indeed. If you clean your solution and try to rebuild it, I suspect it might error out at that point since there may still be some remnants of the X.F binaries in the temp folders. If not, I'd say this is more a Visual Studio bug than a Xamarin bug.

[pfafft33]

I can clean and re-build my app successfully, and it seems to run fine.
How can we get this transferred to the correct Visual Studio issue log?

[ahoke-cr]

Follow the instructions for reporting Visual Studio problems and you can either copy the details and steps you've taken to diagnose the issue into the VS problem report or link this issue thread in your report.