Build the sln file instead of individual project files #159

natemcmaster · 2017-01-31T23:22:07Z

Perf improvement: only builds each project once during the 'build-compile' target.

pranavkm · 2017-01-31T23:38:17Z

build/shade/_k-standard-goals.shade

    }

-    if (projectGlobs.Any())
+    foreach (var sln in Files.Include(Path.Combine(BASE_DIR, "*.sln")))


Could we just build $repoName.sln - seems like a convention all our repos follow. We could throw an error if there happen to be more than one sln.

Yeah, that could be fine. I know off the top of my head that Diagnostics has DiagnosticPages.sln. Are there others?

HttpSysServer still has WebListener.sln though I think WebListener as a repo name will redirect properly

We also need to change that rename in aspnet/Universe's list of repos.

We could throw an error if there happen to be more than one sln.

Meant to say we could throw an error to say we couldn't find the sln if we don't find it.

The only problematic thing is...how do you determine "$repoName"? We can't use directory name as it's not guaranteed....

That's true. I guess we should get Mvc to move the second sln (the NoFun one) out of the repo root as part of the migration. We'll switch to calling dotnet build and have it fail in the non-common cases.

FYI @NTaylorMullen

Bummer, was working around some issues with having multiple sln's in Mvc's migrated makefile. Could we take the approach of having a parameter that we can set to override the default sln name?. It'd be a shame to hide sln's that we actually use from users who clone our repos.

Instead of a parameter, we could build a well known file (build.proj?) if it's present. We can't run dotnet build regardless.

I think this problem can be solved by the work Pranav is doing on #158. The default Korebuild build step could include:

<SolutionsToBuild Include="$(RepoRoot)\*.sln" />

MVC and other repos could customize by adding exclusions to the build/repo.targets file:

<SolutionsToBuild Remove="$(RepoRoot)\Mvc.NoFun.sln" />

natemcmaster · 2017-02-03T20:50:25Z

Almost there: something in Korebuild is attempting to use obj/*.dll...I think.

CSC : error CS2012: Cannot open 'C:\dev\Universe\DependencyInjection\src\Microsoft.Extensions.DependencyInjection\obj\Debug\netstandard1.1\Microsoft.Extensions.DependencyInjection.dll' for writing -- 'The process cannot access the file 'C:\dev\Universe\DependencyInjection\src\Microsoft.Extensions.DependencyInjection\obj\Debug\netstandard1.1\Microsoft.Extensions.DependencyInjection.dll' because it is being used by another process.' [C:\dev\Universe\DependencyInjection\src\Microsoft.Extensions.DependencyInjection\Microsoft.Extensions.DependencyInjection.csproj] [C:\dev\Universe\DependencyInjection.build\targets\makefile.proj]

Doesn't happen when you call "dotnet build" on the solution, w/o korebuild

natemcmaster · 2017-02-03T20:53:26Z

Nvm, it's dotnet/sdk. dotnet/sdk#739

pranavkm · 2017-02-03T23:06:03Z

build/targets/legacy-lifecycle.targets

    </PropertyGroup>

    <Exec
-      Command="$(SakeExecutable) -I $(KoreBuildDirectory)shade -f $(MakeFilePath) $(ShadeTarget)"
+      Command="$(SakeExecutable) -I &quot;$(MSBuildThisFileDirectory)../shade&quot; -f $(MakeFilePath) $(SakeTargets)"


dougbu · 2017-02-04T21:16:12Z

build/targets/common.props

@@ -1,6 +1,7 @@
 <Project>
  <PropertyGroup>
-    <BuildDir>$(RepositoryRoot)\build</BuildDir>
-    <ArtifactsDir>$(BuildDir)\artifacts</ArtifactsDir>
+    <RepositoryRoot Condition="'$(RepositoryRoot)'==''">$(MSBuildThisFileDirectory)..\..\</RepositoryRoot>


This location can easily be incorrect, especially in (nested) test directories. Why isn't this using $([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), "$(Repository).sln") or something similar?

MSBuildThisFileDirectory refers to the location of .build/targets/common.props, not the location of test projects. This value isn't affect by nested test directories.

dougbu · 2017-02-04T21:18:39Z

build/targets/standard-lifecycle.targets


-  <Target Name="Clean" />
+  <ItemGroup>
+    <SolutionsToBuild Include="$(RepositoryRoot)\*.sln" />


This won't work well at least for Mvc. Why not $(RepositoryRoot)\$(RepoName).sln?

The goal here is to make the default case work, which is that we have one sln per repo. MVC and any other solution that has multiple solutions would put something like this in to build/repo.targets:

<SolutionsToBuild Remove="Mvc.NoFun.sln" />

We don't have a good way to determine "RepoName" :-/ as the folder name containing the source code is not guaranteed to match the sln name.

dougbu · 2017-02-04T21:25:26Z

build/shade/_k-standard-goals.shade

+    {
+      Dotnet("msbuild /nologo"
+             + " \"" + Path.Combine(Directory.GetCurrentDirectory(), ".build/targets/makefile.proj") + "\""
+             + " \"/p:LifecycleType=Standard;Configuration=" + E("Configuration") + "\""


With changes to build/targets/makefile.proj, does this command-line lifecycle choice still work?

For now, yes, you can still express build verify and build --for-ci build-compile etc.

natemcmaster · 2017-02-08T22:38:42Z

🆙 📅 Removing the [blocked] label. The race condition in solution builds has been fixed.

natemcmaster · 2017-02-08T22:42:09Z

I added two changes to be aware of.

(1) the tool dependencies (Sake, NuGetPackageVerifier, and NETFrameworkReferenceAssemblies) restore into the regular nuget cache instead of into the .build folder
(2) Update to CLI 1.0.0-rc4-004777

We'll need to update other repos. Any project that has multiple *.sln files or has projects in the solution file that doen't build with dotnet-CLI will need to be updated. Razor, MVC, and possibly others.

This reverts commit 1cc9f90.

natemcmaster · 2017-02-09T01:30:36Z

cc @pakrym

pakrym · 2017-02-09T06:22:34Z

Wouldn't calling pack on each project try to rebuild everything again?

natemcmaster · 2017-02-09T17:01:59Z

At the moment yes it will build twice. This is an incremental step towards eliminating the Sake lifecycle. Some of our repos have custom packaging steps that we need to port to MSBuild.

This has the advantage of only rebuilding projects once during the pack phase. MSBuild will batch the builds during pack.

In a follow up PR, we can move even more into MSBuild so each project should only compile once per build.cmd run.

pakrym · 2017-02-09T17:03:46Z

👍 LGTM

natemcmaster requested a review from pranavkm January 31, 2017 23:22

dnfclas added the cla-already-signed label Jan 31, 2017

pranavkm approved these changes Jan 31, 2017

View reviewed changes

pranavkm approved these changes Feb 1, 2017

View reviewed changes

natemcmaster mentioned this pull request Feb 3, 2017

Use makefile.proj if available #158

Closed

natemcmaster force-pushed the namc/incremental branch from 13c1459 to 7228b4e Compare February 3, 2017 19:57

natemcmaster added the blocked label Feb 3, 2017

pranavkm approved these changes Feb 3, 2017

View reviewed changes

dougbu suggested changes Feb 4, 2017

View reviewed changes

natemcmaster force-pushed the namc/incremental branch 2 times, most recently from af694f7 to d7c5079 Compare February 8, 2017 22:19

natemcmaster removed the blocked label Feb 8, 2017

natemcmaster force-pushed the namc/incremental branch from d7c5079 to 8758c60 Compare February 8, 2017 22:44

Revert "Revert "Use dotnet msbuild to launch makefile.shade""

f57e6fc

This reverts commit 1cc9f90.

natemcmaster force-pushed the namc/incremental branch from 8758c60 to 4778c94 Compare February 9, 2017 00:27

natemcmaster mentioned this pull request Feb 9, 2017

Create NoVSIX solution configurations aspnet/Razor#985

Merged

Build solution files

6616302

natemcmaster force-pushed the namc/incremental branch from 4778c94 to 6616302 Compare February 9, 2017 22:22

natemcmaster merged commit 6616302 into feature/msbuild Feb 9, 2017

natemcmaster deleted the namc/incremental branch February 9, 2017 22:31

natemcmaster mentioned this pull request Feb 11, 2017

build.cmd should create a log file #86

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build the sln file instead of individual project files #159

Build the sln file instead of individual project files #159

natemcmaster commented Jan 31, 2017

pranavkm Jan 31, 2017

natemcmaster Jan 31, 2017

JunTaoLuo Feb 1, 2017

natemcmaster Feb 1, 2017

pranavkm Feb 1, 2017

natemcmaster Feb 1, 2017

pranavkm Feb 1, 2017

NTaylorMullen Feb 1, 2017

pranavkm Feb 1, 2017

natemcmaster Feb 1, 2017

natemcmaster commented Feb 3, 2017 •

edited

Loading

natemcmaster commented Feb 3, 2017

pranavkm Feb 3, 2017

dougbu Feb 4, 2017

natemcmaster Feb 6, 2017

dougbu Feb 4, 2017

natemcmaster Feb 6, 2017

dougbu Feb 4, 2017

natemcmaster Feb 6, 2017

natemcmaster commented Feb 8, 2017

natemcmaster commented Feb 8, 2017

natemcmaster commented Feb 9, 2017

pakrym commented Feb 9, 2017

natemcmaster commented Feb 9, 2017

pakrym commented Feb 9, 2017

Build the sln file instead of individual project files #159

Build the sln file instead of individual project files #159

Conversation

natemcmaster commented Jan 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natemcmaster commented Feb 3, 2017 • edited Loading

natemcmaster commented Feb 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natemcmaster commented Feb 8, 2017

natemcmaster commented Feb 8, 2017

natemcmaster commented Feb 9, 2017

pakrym commented Feb 9, 2017

natemcmaster commented Feb 9, 2017

pakrym commented Feb 9, 2017

natemcmaster commented Feb 3, 2017 •

edited

Loading