dotnet / buildtools Goto Github PK

BuildTools is a tools package, it should never be referenced by projects. As such, having dependencies on packages other than other tools packages makes no sense. Build tools can't possibly consume those.

CopyTestToTestDirectory now only happens when the RunTestsForProject target is invoked. This broke the VS flow where build got everything ready and F5 could debug. Now I can only debug in VS if I run the tests on the command line first to copy the right files.

I just tried building corefx with the new Mono 4.0.1SR1 (it backports a fix that made us require >= Mono 4.1). However, it now complains about not having StandardOutputImportance parameter for a Task when building the tests, which is odd because we're using the open-sourced MSBuild which has those (Mono has them too on >= 4.1).

From my observation the issue is that the custom task project in this repo references Microsoft.Build.Tasks.v4.0 and Microsoft.Build.Utilities.v4.0, which isn't there in the open-sourced MSBuild and thus Mono tries in it's GAC and finds Mono's implementation of the assemblies which don't have the required parameter.

While it doesn't cause problems on Mono >= 4.1 right now since it has an implementation for the missing parameter (I actually added it a while back when trying to build corefx with xbuild), this is probably something that should be fixed so it loads the MSBuild 14 assemblies instead. I can see this being very confusing otherwise down the road ;)

/cc @JeremyKuhne

A recent change was made so that the ResolveNugetReferences now populates the ReferenceCopyLocalPaths item group. This causes every nuget file to copied locally, with no way to prevent it.

At least one tools needs to be able to prevent that behavior, so that only the built files end up in the output directory.

A property should be created to prevent this default behavior. Perhaps SkipNugetCopyLocal, or something.

See #197 and #208.

Remaining tasks for reenabling hardlinks on xplat builds:

• dotnet/msbuild#132
• Publish new MSBuild package containing the above fix and use it in corefx etc

I notice that the nuget (http://www.nuget.org/packages/Microsoft.DotNet.BuildTools) has been delisted...

Any ideas what I'm doing wrong?

We have a couple of Windows-only libraries:

• System.Security.Principal.Windows
• System.Security.Cryptography.Csp
• System.Security.Cryptography.Cng
• Probably others
  and each of these libraries has to mark their tests as

<UnsupportedPlatforms>Linux;OSX</UnsupportedPlatforms>

When we define a new platform (e.g. FreeBSD) all of these test libraries are going to have to be touched to say that they won't support it.

For something which is a common-Unix concept (such as the OpenSsl crypto sub-library) <UnsupportedPlatforms>Windows_NT</UnsupportedPlatforms> might make sense, but otherwise it feels to me like once it's platform-specific it should be opt-in.

Roslyn uses the buildtools for core-clr projects and we've found that VS 2015 deadlocks while running the dnx.exe binary continuously in the background when loading a project that imports the buildtools targets. Try opening https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/CscCore/CscCore.csproj in VS 2015 for a repro of the issue.

There are no tests in the BuildTools repo. The Tasks project could use tests both for the custom tasks themselves, as well as the targets files (e.g. importing all of the targets into a master build file and at least ensuring that they parse correctly). I haven't looked enough at the other projects in the repo to know what kinds of tests would be appropriate, but they do contain non-trivial logic that could be tested.

Now that this is supported in the portable System.Console library: https://github.com/dotnet/corefx/issues/3558, we should be able to use it in the command line parsing helper. See:
https://github.com/dotnet/buildtools/blob/master/src/common/CommandLine.cs#L1705

Currently to run the tests on FreeBSD, one of the stoppers is TemporaryTestHost. We tried building with Linux test-host, but it fails all the tests as discussed here https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303. The error message when using linux temporary host is:

./run-test.sh: line 172:  3844 Abort trap              (core dumped) ./corerun xunit.console.netcore.exe $testDllName -x
ml testResults.xml -notrait category=failing -notrait category=OuterLoop -notrait category=$xunitOSCategory

Please make the buildtools available for FreeBSD at:
https://www.myget.org/F/dotnet-buildtools/api/v2/package/Microsoft.DotNet.CoreFx.FreeBSD.TemporaryTestHost/0.0.2-prerelease

which is required at corefx/run-test.sh#L100-L104, so we can further our progress.

/cc @mmitche, @akoeplinger, @josteink

...at least on non-Ubuntu distros: an incorrect tool runtime is being deployed, which causes chmod a+x <ToolRuntimePath>/corerun to fail.

It seems like our current test targets (or perhaps resource targets) don't copy over satellite resource assemblies for other languages, if they exist. I could take a stab at this if someone pointed me to where the fix should be made. I mainly wanted this so I could add some tests to ResourceManager that tried grabbing strings from other languages than the default.

Today the runtime to run our tools under gets deployed to a ToolRuntime folder in $(BaseOutputPath)\$(OSPlatformConfig), I think that $(IntermediateOutputRootPath) (e.g. bin\obj\Linux.AnyCPU.Debug) is a better place for it. What do you think @weshaggard?

(from @eatdrinksleepcode in dotnet/corefx#678)

Executing a build twice in a row should ideally be as close to a no-op as possible. In CoreFX, unit tests are always executed during the second run, even when the both the main and test project have not changed. This could be fixed by specifying the correct Inputs and Outputs to the RunTests task. I would be happy to submit a PR with this change to the BuildTools project.

The Target files are listed as Content items as well as None items. The Content items have an incorrect tag so they don't show up in VS but they do control the copying of those files to the output. However the None tags don't do anything but show the files in VS. We can tweak the metadata in the Content tags and delete the None items to get these showing up in VS correctly and copying correctly without the duplicated entries.

We should avoid hardcoding the paths and version of these tools in our targets. See #156 for a place where we had to fix this. Also @ericstj comment about an example to use as a model.

Today test build and execution are intertwined. This means if I have tests with platform specific code (at build time) it's not easy for me to build them on a different platform than I would run them on.

We should enable this. CoreFX could then use this to build Linux and OSX versions of the tests instead of always using the windows versions when running cross platform.

I was talking to @jhendrixMSFT today and we both agreed that Microsoft.DotNet.PerfTools should be deleted from this repo (now that we know it will be replaced with xunit.performance).

Those are basically two bugs:

• Xunit runner runs tests on all binaries inside bin folder instead of only built binaries
• build /t:clean do not remove old binaries from bin folder

Repro:

• build
• rename any csproj with tests by simply changing AssemblyName property
• build

Effect: tests of rename binary run twice

• build /t:clean
• build

Effect: tests of rename binary run twice

• remove bin folder
• build

Effect: tests run as they should (once per binary)

Currently there is no straight forward way to annotate the test with ActiveIssue without disabling it.

I have couple of tests which do not fail but test design decisions which need to be reevaluated.

I want to annotate the tests so it is easy to find them when fixing the issue but not disable them.

Currently you can workaround by using:

[ActiveIssue(1234, default(PlatformID))]

or hacking with Xunit's Trait attribute and passing the right magic values.

When adding nuget reference to xunit.runner.visualstudio it breaks the build:

xunit visualstudio runner is adding some dlls in the output directory and one of the binaries happen to match our wildcard:
dll: xunit.runner.visualstudio.testadapter.dll
pattern: $(OutDir)\test.dll

which causes errors to appear when it tries to run the tests on this binary.

Over time, we have increased the amount of settings and configuration needed to get a blank project building with the buildtools package. From the https://github.com/dotnet/corefx repo, the following msbuild files are all needed to build, or exist because of workarounds on various platforms, etc:

• build.proj
• dir.props
• dir.targets
• dir.traversal.targets
• mono.targets
• override.targets
• roslyn.xplat.targets
• src/BuildValues.props
• src/dir.props
• src/dir.targets
• src/dirs.proj
• src/.nuget/packages.Windows_NT.config
• src/.nuget/packages.Unix.config

Not all of the configuration above is strictly necessary for a blank build, but a lot of it is. There's also a very substantial amount of stuff in some of the files, like dir.props, dir.targets, and dir.traversal.targets.

We should try to consolidate some of the common properties into buildtools itself, and perhaps provide a sample template for minimal builds using buildtools.

While working on #116, I kept running out of disk space: I would free some up, but then just a few minutes later the drive would be full again. I discovered that a full build of CoreFX is adding over half a gig to the NuGet cache (%TEMP%\nuget), even with no changes and nothing new to download. I narrowed this down to the ResolveNuGetPackages task: something about this task is causing new packages to appear in the cache, even when they should already be there.

Right now, we are only producing a Windows version of GenFacades. When we have cross-plat NuGet packages to consume, we should be able to add additional build configurations for other platforms.

We should look for another solution that doesn't requiring an explicit Touch of nuget.exe and the buildtools library at the end of RestoreBuildTools target in dir.targets.

The reason it was added was to deal with the case where people didn't actually delete their packages directory but they got an updated dir.props file and in that case they could get into a loop where RestoreBuildTools always runs every time for every project and slows down the build.

a385cfb seems to have broken the ability to run Unit Tests inside VS. The transformation for {XunitTraitOptions} doesn't seem to happen when loading the project inside VS, so the command line we pass when the test project is set as the startup project is incorrect and causes the test runner to exit with an error.

Do we need to do something specific here when running under VS?

A recent change switched us to using this contract in the xunit.netcore.extensions assembly, but we didn't add the dependency to the NuGet package, so users of the package will have to add it themselves after they see the error.

See dotnet/corefx#950. There is currently a dependency on the nupkg explicitly mentioning aspnetcore50.

I'm working around it with a binary reference while excluding the package from packages.config. (This only works because we have to build the src/ project first which guarantees that the package will have been restored.)

Repro steps in dotnet/corefx

1. Clean entire enlistment (git clean -fdx)
2. Remove any or to System.Collections.Immutable.dll from System.Reflection.Metadata.Tests.dll.
3. Add System.Collections.Immutable to System.Reflection.Metadata.Tests packages.config
4. Build System.Reflection.Metadata.sln in VS
5. Set tests as startup project
6. Run (Cltrl+F5)

Expected result
Build succeeds without warning and tests run successfully.

Actual result
Build warns about not "finding a matching group" and tests fail due to missing System.Collections.Immutable.dll.

The xunit netcore console runner has drifted significantly from the full xunit console runner. We should work with the xunit team to incorporate whatever changes are necessary to support .NET Core, and then adopt the official runner in build tools rather than having a forked runner.

fxbuild.proj defaults configuration to Release which is somewhat unexpected when building and testing locally. It makes some things like debugging more difficult. I would only expect the build machines to pass Release as the default or people that explicity set it.

    <Configuration Condition="'$(Configuration)'==''">Release</Configuration>
    <Platform Condition="'$(Platform)'==''">Any CPU</Platform>

We should do something similar to what Microsoft.Common.CurrentVersion.targets does which is:

   <Configuration Condition=" '$(Configuration)'=='' ">Debug</Configuration>
   <Platform Condition=" '$(Platform)'=='' ">AnyCPU</Platform>

In 2343d6f the Copy task in publishtest.targets was set to UseHardlinksIfPossible="true". However, the xplat MSBuild doesn't implement hardlinks in a cross-platform way currently (it just pinvokes into CreateHardlink Windows API), so this crashes on !Windows.

We should probably check for the OS in publishtest.targets and try hardlinks only on Windows (since tests aren't run via msbuild on other platforms yet anyway).

/cc @JeremyKuhne @nguerrera

Per the discussion at dotnet/corefx#782, we're scrubbing [ComVisible] attribution from the CoreFX sources. If the resolution of that discussion is that we should have an [assembly: ComVisible(false)] attribute in every assembly, we should put it in the generated _AssemblyInfo.cs file that's generated as part of the build.

@weshaggard Thanks for helping figure this out.

This will enable managed test projects that use project references to native projects to publish the native output to the test drop. This would fix the issue I mentioned in #1013

The root of this problem is because binaries.targets has the following:

    <_BinariesProjectProperties>
      Configuration=$(Configuration);
      Platform=$(Platform);
      BaseOutputPath=$(BaseOutputPath);
      BaseIntermediateOutputPath=$(BaseIntermediateOutputPath);

      ToolsDir=$(ToolsDir);

      CoreResGenDependsOn=$(CoreResGenDependsOn);GenerateResourcesSource;GenerateStringResources;
      CustomBeforeMicrosoftCommonTargets=$(ToolsDir)beforecommon.targets;
    </_BinariesProjectProperties>

So all these options like output and intermediate paths are only set from the root build.proj and if you build a given project locally from the command line or within VS the binaries get put into different places and have different targets executed. Things like signing, packaging, resource generation, are not happening unless you build from the root.

We need to have a principle of making the building of an individual csproj should be consistent across all the ways of building it (i.e. directly, from solution, from root, from both command line and within VS).

The buildtools resolution of nuget assets was a bootstrapping mechanism as we got things to build with the .NET Core packages pending official support. Once the official support is broadly available, we should change the targets to detect this and use the built-in targets wherever possible.

I'm currently preparing a temporary hack to rename some things such that buildtools does not conflict with VS and always uses its own targets. This is just to unblock things for internal devs quickly.

Once possible, we will need to decide if we can take a required dependency on a version of VS with the built-in targets or if we want to allow building with older versions of VS by falling back to the code in buildtools.

cc @ericstj @ljw1004

#226 moved AssemblyInfo.cs to a path that can be common if projects have the same name. I hit this in the reference assembly projects and worked around it. I think the right fix here is to split out just the attributes needed by #217 and make those in a stable path that is shown in solution explorer. Ideally you can just ship a static file in build tools so you don't have to worry about building before it shows up. I didn't do this myself since I'm not familar with the tool you mention in the PR. Can you please have a look and clean this up? When you do feel free to delete my workaround.

Today project.lock.json and some of our targets force a 32 bit runtime when running tests. I think we should move this to x64. This aligns with what we are doing cross platform and will make it easies to produce runtime packages from github (where we don't have an x64 version of the runtime).

Are there any concerns about adopting a x64 bit runtime?

/cc @mellinoe @weshaggard @ericstj @stephentoub

The TFM we use today is bogus. It's the PCL TFM for net45+win8. We should be using a TFM that is more appropriate for what we are building. I suspect this will be the new TFM created for "package based portable" once it exists. Right now this issue is blocked on PCL work in Dev14.

As we bring up our contract/reference assembly build here, we should think about where ApiCompat comes into play and work towards open-sourcing it if we are going to need to use it cross-plat.

Currently, we're using a really old version of buildtools, and the .NET Core Xunit assemblies we build in this repo are building against very old versions of our NuGet packages (very different from the latest packages), and are still using packages.config files. We should update these to be in line with corefx.

BuildTools currently only supports testing against Core. However, Microsoft.DotNet.Build.Tasks is built against the full framework, and must continue to be at least until MSBuild is available for Core. Therefore the corresponding unit test project must also be built and run against the full framework. In order for BuildTools to continue dogfooding itself, it must support testing against the full framework.

There are two potential ways to go about this:

1. Allow the TestHost and XunitExecutable properties to be overridden. The project would then be required to set these properties correctly, as well as provide the full framework version of xunit.
2. Expose a UseCoreForTest property (or similar) that makes the required changes automatically, and also pulls in the correct version of xunit. This would make this functionality more reusable, however I am leaning away from it for two reasons:
   • Core vs full framework is already not transparent to the test project; it has to have the correct xunit reference to start with, and the build tools do not provide the compile-time references (although perhaps they could??).
   • It is my impression that few if any projects intend to use these build tools while targeting the full framework. If we put this functionality into the build tools, and then MSBuild becomes available on Core and the BuildTools are converted to Core, then it will be a change to the BuildTools to remove this functionality. If instead we allow these properties to be overridden, and put the full framework references into the unit test project, then it is just a change to the unit test project to take them out. On the other hand, if my assumption is wrong and there are more projects that target the full framework that could benefit from using BuildTools, then that is a stronger argument for 1 over 2.

See Program.cs#L488

We replicated the behavior of csc.exe at the time. However, some tools get upset when they find an exported type entry that can't resolve even if there is no actual use of the entry encountered. Those tools should be hardened appropriately, but we might as well also help them out by not emitting what isn't necessary.

Things to consider:

• InternalsVisibleTo: I am not certain how type forwards behave relative to it, but I believe it would depend on whether the caller is a friend of the destination. We may want to keep anything that is visible to friends and only cull things invisible outside assembly even in the face of InternalsVisibleTo.
• Check the behavior of Roslyn. Does it still emit these from a [TypeForwardedTo(TopLevelTypeWithPrivateNestedTypes)]?) If so, we should file a bug against the compiler as well.

Currently, in the CopyTestsToTestDirectories target, we sometimes end up with the same dll from different package versions (I believe this happens when product dependencies outpace the coreclr/buildtool package dependencies but I did not confirm). Right now, we just arbitrarily copy the last one in the list over the previous ones with the same file name. In addition to not being very well defined, it breaks SkipCopyUnchnagedFiles.

The aspnetcore50 TFM is obsolete. We should remove it from the xunit.console.netcore NuGet package and update test.targets to refer to a different folder.

Please release Microsoft.DotNet.BuildTools-1.0.16-prerelease on GitHub. Currently it is available on Nuget.org: http://nuget.org/packages/Microsoft.DotNet.BuildTools, but not in GitHub releases: https://github.com/dotnet/buildtools/releases.
Thanks.

In the exec task, all of the compile items get listed with semicolons between them.

It should be as simple as turning this:
@(Compile)

Into this:
@(Compile, ' ')