-
Notifications
You must be signed in to change notification settings - Fork 74
Conversation
|
||
<Target Name="Test"> | ||
<MSBuild Targets="VSTest" | ||
Projects="@(TestProjects)" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will run test assemblies in parallel. You may want to use task batching (i.e. Projects="%(TestProjects.Identity)"
) to prevent this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I lied. BuildInParallel
defaults to false
. But in that case, you may want to consider adding it wherever you use the MSBuild
task with multiple projects. It does a topological sort (based on ProjectReference
items) and builds the parts in can in parallel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Would be good if it works well. I'll play it. Not sure how well VSTest handles parallel test projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should test in parallel. Just build/pack.
</PropertyGroup> | ||
<ItemGroup> | ||
<SourceProjects Include="src\*\*.csproj" /> | ||
<TestProjects Include="test\*\*.csproj" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've always wanted the unit tests to run before functional/integration/end-to-end tests... It seems like a good way to "fail fast".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be awesome. My MSBuild-ese isn't quite good enough to know the best way to code a good sorting algorithm like that....does the .NET Core MSBuild support code tasks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the .NET Core MSBuild support code tasks
Not last I checked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just do it in two passes.
<ItemGroup>
<UnitTestProject Include="test/**/*.Test.csproj" />
<OtherTestProject Include="test/**/*.csproj" Exclude="@(UnitTestProject)" />
</ItemGroup>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's easier. added it.
throw 'Restoring packages for build.xml failed' | ||
} | ||
& $env:DOTNET_HOME/dotnet.exe msbuild build.xml /nologo /v:m $args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add /m
for a bit more oomph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooh, nice. Yeah, let's put that CPU to work
<Target Name="Pack"> | ||
<MSBuild Targets="Rebuild;Pack" | ||
Projects="@(SourceProjects)" | ||
Properties="PackageOutputPath=$(ArtifactsPath)" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May also want to flow Configuration=$(Configuration)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(On other MSBuild
usages too.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So i'm still a little fuzzy on how properties flow form outer to inner builds, but I thought properties like Configuration
just automatically flow into inner builds unless explicitly listed in 'RemoveProperties'...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling the MSBuild task creates a new context/scope--no properties are preserved unless you pass them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, the RemoveProperties
is used to remove properties specified in the Projects
items' Properties
and AdditionalProperties
metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<ItemDefinitionGroup>
<Project>
<AdditionalProperties>C=C</AdditionalProperties>
</Project>
</ItemDefinitionGroup>
<ItemGroup>
<Project Include="SomeProject">
<Properties>A=A;B=B</Properties>
</Project>
</ItemGroup>
<!-- Flow B, C & D, but not A -->
<MSBuild Projects="@(Project)" RemoveProperties="A" Properties="D=D" />
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ❤️ MSBuild. (In a Stockholm syndrome kind of way)
</Target> | ||
|
||
<Target Name="Pack"> | ||
<MSBuild Targets="Rebuild;Pack" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why force a full rebuild every time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Will remove.
<?xml version="1.0" encoding="utf-8"?> | ||
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> | ||
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" /> | ||
<Import Project="..\..\build\common.props" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
..........
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remind me, by default this is relative to the project file right? I still think this should be a package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by default this is relative to the project file right?
Yes.
I still think this should be a package.
Agreed. As per ongoing discussion in https://github.com/aspnet/specs/pull/49, I fully intend to move most of these common properties to a package. When that happens, we can remove duplication from that file. That said, there is still a high chance we will still want a common.props file per repo for settings that truly are repo specific, such as RepositoryUrl
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is relative to the project file right
Yes, the project you pass to msbuild
, and you use $(MSBuildThisFileDirectory)
to reference files relative to the current one.
<!--<PackageReference Include="Microsoft.Extensions.Process.Sources" Version="1.1.0-*" PrivateAssets="All" />--> | ||
|
||
<!-- ExcludeAssets="build" to workaround https://github.com/dotnet/corefx/issues/12913 --> | ||
<PackageReference Include="Microsoft.DiaSymReader.Native" Version="1.4.0" ExcludeAssets="build" PrivateAssets="All" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a workaround for dotnet/roslyn#15137. Just checked again and the workaround can be removed now.
dc8938c
to
13e6424
Compare
⌚ Putting this work on hold. Found some un-workaround-able issues. microsoft/vstest#241 - dotnet test returns exit code 0 even when tests fail |
1e99fc1
to
e71a8f2
Compare
<TargetFramework>netcoreapp1.0</TargetFramework> | ||
</PropertyGroup> | ||
<ItemGroup> | ||
<PackageReference Include="NuGetPackageVerifier" Version="1.0.1-*" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Version 1.0.2-*?
a5abd62
to
180586c
Compare
🆙 📅 Changing course. Sticking with KoreBuild for now to simplify our conversion process. Removing wip: label. This PR is ready. cc @prafullbhosale can you take a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good.
</PropertyGroup> | ||
|
||
<PropertyGroup Condition="$(PackWithoutBuildNumber)"> | ||
<PackageVersion>$(VersionPrefix)</PackageVersion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this being set in case PackWithoutBuildNumber == false
? or does it not need to be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this repo, version.props has it...but you make a good point. This should be made safer so that it can be generalized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version.props only sets the VersionPrefix
and VersionSuffix
but not the PackageVersion
.
Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, PackageVersion is in NuGet's pack targets. It defaults to $(Version)
but can be overridden if you want the pkg version to differ from the build version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Did not know that.
<PackageType>DotnetCliTool</PackageType> | ||
</PropertyGroup> | ||
<ItemGroup> | ||
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would rather have this package reference included in every csproj to be explicit.
@@ -2,10 +2,5 @@ | |||
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information. | |||
|
|||
using System.Reflection; | |||
using System.Resources; | |||
|
|||
[assembly: AssemblyMetadata("Serviceable", "True")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still required? This seems to be set in the pack options in common.props
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, still required. This is different from the serviceable tag on the nupkg.
a109f19
to
902ff8d
Compare
Please take a look. The migration of project.json to csproj is mostly done. The shared infrastructure around it needs work (e.g. KoreBuild's replacement).
Resolves #179
cc @bricelam