Skip to content

Conversation

livarcocc
Copy link
Contributor

Fixes #1025

@dotnet/dotnet-cli

@gulbanana
Copy link

So if i want to build netstandard 2.0 libraries which don't risk accidentally referencing netfx packages, would it be correct to set property DisableImplicitPackageTargetFallback to True?

… It returns not zero when tests are skipped as well. Instead, let's rely on Jenkins validating the xml file.

Fixing the test that I implicit set to fail to test Jenkins xml test parsing. Also changing the name of the test projects to avoid conflict when using the files.
@livarcocc
Copy link
Contributor Author

@gulbanana yes. also, unless you explicitly turned it off, when ptf is used, you will get a warning.

@livarcocc
Copy link
Contributor Author

@dotnet-bot Test Windows_NT_FullFramework Debug

@livarcocc
Copy link
Contributor Author

@dsplaisted @nguerrera PTAL

</Exec>

<Error Text="There were test failures, for full log see %(XmlTestFile.FullPath)" Condition="$(ExitCode) != 0" />

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed it because xunit returns non-zero even when we have skipped tests. Which now that we have skip attributes happened and caused the build to fail. We don't need this anymore because we are parsing the testResult.xml file and jenkins will fail if there are any failed tests in there.

}
catch
{
// No-Op; as this is a precaution - do not throw an exception.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you just moved this, but it's sloppy to catch all exceptions. We can introduce any bug at all in the try block and never know. Why is it just a precaution to remove these artifacts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johnbeisner can you help clarify this?

}
}

[WindowsOnlyTheoryAttribute]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: drop the Attribute suffix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Copy/paste. Will do.

[InlineData("netcoreapp2.0")]
public void Net461_is_implicit_for_Netstandard_and_Netcore_20(string targetFramework)
{
if (UsingFullFrameworkMSBuild)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're getting better at xunit, should we have some sort of attribute to indicate core msbuild only?


foreach (var additionalProperty in AdditionalProperties)
{
propertyGroup.Add(new XElement($"{ns}{additionalProperty.Key}", additionalProperty.Value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be ns + additionalProperty.Key like the others above.

You want https://msdn.microsoft.com/en-us/library/system.xml.linq.xnamespace.op_addition(v=vs.110).aspx, not string concatenation. I suspect this is only working now because the projects under test have no namespace declared.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

[WindowsOnlyTheoryAttribute]
[InlineData("netstandard2.0")]
[InlineData("netcoreapp2.0")]
public void Net461_is_implicit_for_Netstandard_and_Netcore_20(string targetFramework)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't include the values of the theory parameters in the name of the test. I'd call it something like Net461_is_implicit_package_target_fallback.

string targetFramework,
Dictionary<string, string> additionalProperties = null)
{
_net461PackageReference = CreateNet461Package();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels messy to use a field of the class to pass this object around. I think I'm used to tests not storing any instance state.

var net461Project =
new TestProject
{
Name = $"net461_pkg",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no need for $ in front of string here.

}

[WindowsOnlyFact]
public void It_is_possible_to_disabled_net461_implicit_package_target_fallback()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: change disabled to disable in the method name.


namespace Microsoft.NET.TestFramework
{
public class CoreMSBuildAndWindowsOnlyTheoryAttribute : TheoryAttribute
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Roslyn has a nice pattern for combining common skip conditions: https://github.com/dotnet/roslyn/blob/master/src/Test/Utilities/Portable/Assert/ConditionalFactAttribute.cs

I think we should steal it as it allows composing things like WindowsOnly and CoreMSBuildOnly and also has the benefit of consistency with other dotnet repos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do that in a separate PR though? I would like to merge this one and then we can bring that over.

I agree that's much better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants