Unknown suppression TreatAsOutOfBox

[StephenBonikowsky]

#2667 ported #2649 but in the uwp6.1 branch I get the following failure that we don't in Master...

E:\A_work\2035\s\wcf\Tools\Packaging.targets(1103,5): error : Unknown suppression TreatAsOutOfBox [E:\A_work\2035\s\wcf\src\System.ServiceModel.Http\pkg\System.ServiceModel.Http.pkgproj]

The uwp6.1 branch was snapped from the uwp6.0 branch which was in turn snapped from Master back in summer, so in many ways it is quite far behind Master such as buildtools versions and other dependencies.

@ericstj and @joperezr do you have any idea what I might need for this suppression to be understood?

[StephenBonikowsky]

I think I may have figured out the issue.
While we may want to suppress this in Master and going forward, in the uwp6.1 branch I think we actually want to...
<InboxOnTargetFramework Include="$(UAPvNextTFM)" />

[ericstj]

E:\A_work\2035\s\wcf\Tools\Packaging.targets(1103,5): error : Unknown suppression TreatAsOutOfBox [E:\A_work\2035\s\wcf\src\System.ServiceModel.Http\pkg\System.ServiceModel.Http.pkgproj]

This means the version of buildtools you are using doesn't understood the TreatAsOutOfBox string.

@ericstj and @joperezr do you have any idea what I might need for this suppression to be understood?

You need to update the version of buildtools you are using.

[StephenBonikowsky]

Ok, that makes sense, the uwp6.1 version of buildtools we are using was snapped way back in July.

[StephenBonikowsky]

@ericstj I found your change in buildtools dotnet/buildtools#1657 and ported it to the uwp6.1 branch dotnet/buildtools#1967
I tested it locally and while I no longer got the TreatAsOutOfBox error, I am getting a validation error. I'm not sure if this is an error that should be suppressed or if it is legitimate.

C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.NetTcp should support API version 4.1.3.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.NetTcp should support API version 4.1.3.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\pac kages\System.ServiceModel.NetTcp\4.3.0\ref\netcore50\System.ServiceModel.NetTcp.dll was found to support 4.1.1.0. [C:\OSS\WCF\src\System.ServiceModel.NetTcp\pk g\System.ServiceModel.NetTcp.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.NetTcp should support API version 4.1.3.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\pac kages\System.ServiceModel.NetTcp\4.3.0\lib\netcore50\System.ServiceModel.NetTcp.dll was found to support 4.1.1.0. [C:\OSS\WCF\src\System.ServiceModel.NetTcp\pk g\System.ServiceModel.NetTcp.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Security should support API version 4.0.4.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\p ackages\System.ServiceModel.Security\4.3.0\ref\netcore50\System.ServiceModel.Security.dll was found to support 4.0.2.0. [C:\OSS\WCF\src\System.ServiceModel.Sec urity\pkg\System.ServiceModel.Security.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Security should support API version 4.0.4.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\p ackages\System.ServiceModel.Security\4.3.0\lib\netcore50\System.ServiceModel.Security.dll was found to support 4.0.2.0. [C:\OSS\WCF\src\System.ServiceModel.Sec urity\pkg\System.ServiceModel.Security.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Duplex should support API version 4.1.1.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\pac kages\System.ServiceModel.Duplex\4.3.0\ref\netcore50\System.ServiceModel.Duplex.dll was found to support 4.0.2.0. [C:\OSS\WCF\src\System.ServiceModel.Duplex\pk g\System.ServiceModel.Duplex.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Duplex should support API version 4.1.1.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\pac kages\System.ServiceModel.Duplex\4.3.0\lib\netcore50\System.ServiceModel.Duplex.dll was found to support 4.0.2.0. [C:\OSS\WCF\src\System.ServiceModel.Duplex\pk g\System.ServiceModel.Duplex.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Http should support API version 4.1.3.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\packa ges\System.ServiceModel.Http\4.3.0\ref\netcore50\System.ServiceModel.Http.dll was found to support 4.1.1.0. [C:\OSS\WCF\src\System.ServiceModel.Http\pkg\System .ServiceModel.Http.pkgproj] C:\OSS\WCF\Tools\Packaging.targets(1103,5): error : System.ServiceModel.Http should support API version 4.1.3.0 on UAP,Version=v10.0.16299 but C:\OSS\WCF\packa ges\System.ServiceModel.Http\4.3.0\lib\netcore50\System.ServiceModel.Http.dll was found to support 4.1.1.0. [C:\OSS\WCF\src\System.ServiceModel.Http\pkg\System .ServiceModel.Http.pkgproj]

[StephenBonikowsky]

@ericstj you said in the other PR...

In uwp6.1 branch you need to update your package index to correctly represent what you shipped in uwp6.0.

I think that is what these current errors are all about. I just need to verify that the versions listed by the errors are correct before just changing them to match.

[ericstj]

First step is to merely update the packageIndex. You should update it with the stable versions you shipped in 6.0. This will cause the harvesting to start picking up your last shipped package.

[StephenBonikowsky]

So WCF never shipped any packages for UWP, we did build packages but instead of releasing them we provided them to whoever was producing the uwp meta-package.

We never put a stable package for uwp6.0 on MyGet. Should we create one for this type of purpose?

[ericstj]

I see, so you really need to assert what you want to do going forward:

1. Only ever ship inside the UWP metapackage.
2. Ship in both the UWP metapackage and WCF packages.

If you choose 1 it means your API is frozen, you'll only ever be able to add API in a new NETStandard version that doesn't map to a UWP version. To execute on this you just need to make sure you have placeholders and the inbox entries correctly listed in the index.

If you choose 2 (which is what I was recommending) your API is not frozen, but you'll need to carry an implementation assembly which can apply and satisfy the version of the ref on all places it applies. To execute on this you need to ensure you have an implementation which applies to UAP inside the package and matches the ref. For example: building a live configuration of System.Private.ServiceModel that targets uap10.0.16299 (as well as for the ref/src projects for all your contracts). So simply updating many of your configurations to use uap10.0.16299 instead of uap may be all you need to do. Of course you'll need @joperezr's changes that bring in the references for uap10.0.16299.

[StephenBonikowsky]

Ok, thanks @ericstj, @zhenlan and I need to discuss this.

[ericstj]

Sure, one thing to consider is that 2 isn't much different than how you're handling netcoreapp, except in that case you continue to target netstandard which means netstandard2.0 which applies to both netcoreapp2.0 and netcoreapp2.1. The thing that makes UWP slightly different is that these were inbox.

[StephenBonikowsky]

Fixed with dotnet/corefx#1967