CaringDev
commented
1 year ago Fixed by https://github.com/bbvch/LambdaTale/pull/14/files If anyone has an explanation... I'm still interested :-)
Closed CaringDev closed 1 year ago
CaringDev
commented
1 year ago Fixed by https://github.com/bbvch/LambdaTale/pull/14/files If anyone has an explanation... I'm still interested :-)
bradwilson
commented
1 year ago This definitely seems like a bug, as we shouldn't be doing the {Platform} replacement unless you ask for it. I'm glad you've found a workaround, though I worry that you'll be broken if someone tries to use your library on .NET Framework (which will try to substitute desktop instead of dotnet for the {Platform} replacement token).
bradwilson
commented
1 year ago I'm aware of Why doesn't xUnit.net support netstandard? but thought this is related to runners / running and not assemblies, that need to be loaded.
Yes, that's true, though the library you're trying to extend has two different versions (.NET Framework vs. everything else) because there is functionality that cannot be implementation with just .NET Standard 1.1, which is what this library multi-targets to (net452 and netstandard1.1). If you search the source of xunit.execution for #if NETFRAMEWORK you can see where those differences are.
bradwilson
commented
1 year ago Ah! This is why:
You should remove this, as that's the flag that tells us to do the {Platform} replacement. You should also undo the changes in https://github.com/bbvch/LambdaTale/pull/14 at the same time.
bradwilson
commented
1 year ago The XML comments describe what it does: https://github.com/xunit/xunit/blob/c6073bb042a4c081e0f1c1300d75ab44d0c41aaf/src/xunit.core/Sdk/PlatformSpecificAssemblyAttribute.cs#L5-L32
/// <summary>
/// Marks an assembly as a platform specific assembly for use with xUnit.net. Type references from
/// such assemblies are allowed to use a special suffix ("My.Assembly.{Platform}"), which will
/// automatically be translated into the correct platform-specific name ("My.Assembly.desktop",
/// "My.Assembly.win8", etc.). This affects both extensibility points which require specifying
/// a string-based type name and assembly, as well as serialization.
///
/// In v2.1 and later, the supported platform target names include:
///
/// "desktop" (for desktop and PCL tests),
/// "dotnet" (everything else).
///
/// In v2.0, the following names were also supported:
///
/// "iOS-Universal" (for Xamarin test projects targeting iOS),
/// "MonoAndroid" (for Xamarin MonoAndroid tests),
/// "MonoTouch" (for Xamarin MonoTouch tests),
/// "universal" (for Windows Phone 8.1 and Windows 8.1 tests),
/// "win8" (for Windows 8 tests),
/// "wp8" (for Windows Phone 8 Silverlight tests).
///
/// For backward compatibility reasons, the v2.1 runners will support tests linked against
/// the v2.0 execution libraries.
///
/// Note that file names may be case sensitive (when running on platforms with case sensitive
/// file systems like Linux), so ensure that your assembly file name casing is consistent, and
/// that you use the suffixes here with the exact case shown.
/// </summary>Ah, as expected: my bad 🙈 @bradwilson thank you very much for the close look and detailed explanation and even instructions 🙏 I'll try that tomorrow 👍
While trying to bring forward a successor for xBehave, I most likely run into a misunderstanding of how to extend xUnit. After getting rid of
{Platform}specific Execution projects I get the following Test output. The tests are shown in VS Test Explorer but cannot be run (Rider, R# in VS anddotnet testwork as expected). I'm aware of Why doesn't xUnit.net support netstandard? but thought this is related to runners / running and not assemblies, that need to be loaded.Please find here a MRE.
I cannot find any mention of the
{Platform}string. Searching for theCatastrophic error during deserializationlead me to trying to find an ominous VS Test Explorer Extension cache dir but this seems to be gone.Would you have any hints?