Cannot pair to mac server when building TFM Xamarin.iOS in Visual Studio 2017

[tranb3r]

So far, I've not been able to multi-target with xamarin.ios tfm, using vs 2017 (windows).

How to reproduce the issue:

• in visual studio 2017 (windows)
• create a new netstandard library
• edit csproj, add xamarinios10 to TargetFrameworks (multitargeting with msbuildsdkextras 1.5.4)
• "pair to mac" option is not possible in visual studio
• as a consequence, the assembly will not be built on the mac server (warning VSX1000: No Address and User has been specified in order to establish a connection to a Mac Server)

If you add a xamarin.ios library to the same solution, the "pair to mac" option is now enabled.
However, building the first assembly still fails with the same warning.

Do you think this issue could be fixed ?
Or maybe this is an issue in xamarin or visual studio ?

[clairernovotny]

You can ignore that warning. Libraries don't build on a Mac, only applications do. @kzu, can that warning be removed for libraries?

[tranb3r]

Understood.
Actually, we have the same warning on a "xamarin.ios class library" when VS is not connected to the mac server.
So this is definitely not specific to multi-targeting, and it's not a big deal since the connection is actually not required for a library.
Thanks !

[kzu]

Does passing /nowarn: from MSBuild work? If not, @mauroa we need to look into that and allow to build class libraries without warnings (maybe we should modify the templates? /cc @joj)

[tranb3r]

When using msbuild (cmd line instead of visual studio), there are actually 2 warnings:

• (SayHello) : warning VSX1000: No Address and User has been specified in order to establish a connection to a Mac Server
• (SayGoodbye) : warning : There is no current Build Connection to get. A new connection needs to be created first

When passing /nowarn:VSX1000, the first warning is suppressed. However the second one is still here.

In visual studio, adding "VSX1000" to csproj does not seem to have an effect.

[bgavrilMS]

There is a somewhat unpleasant workaround described here

I was wondering if the real issue is tracked somewhere?

[kzu]

If you report it at https://developercommunity.visualstudio.com (or via the "Send Feedback" inside VS), we can track it internally and fix it sooner than later in the Xamarin.iOS side. I already filed a work item internally anyway, but a public feedback item will allow you to track it better.

[clairernovotny]

Closing as external