Announcement

Collapse
No announcement yet.

Bridge compiler running on every project in solution, even if no changes.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Bridge compiler running on every project in solution, even if no changes.

    Hi Bridge -

    We are switching from using Nuget references to using project references for our dependent libraries. With the switch we are seeing dramatically longer build times (3 seconds with Nuget to over 15 seconds with many project references). I tracked this down to the fact that the bridge compiler is being run for every project in the solution, whether the code in that project was changed or not, and each time it is invoked it adds 2-3 seconds on to the build time.

    I looked in your Bridge.Min.targets and see that the BridgeNetCompilerTask does not specify Inputs and Outputs, and thus msbuild runs it every time. So, I modified the task as follows:

    <Target Name="BridgeNetCompilerTask" Inputs="$(OutputPath)$(AssemblyName).dll" Outputs="$(OutputPath)bridge\$(AssemblyName).js">
    I was excited to see that this solved the build time problem! And, it also correctly call bridge on each project that actually had code changes.

    However, it causes a problem. The top level project that creates the index.html page and needs to include all .js files for the lower projects is no longer being built correctly. Specifically, if a dependency is not rebuilt because there were no changes, that dependency's .js files are not being copied, nor is the html file including references to them.

    I turned on tracing and tracked down the problem. In a full build, the top level project pulls the Bridge.Resources.json file as follows:

    2019-03-19T13:19:01:473 Trace Checking if reference ClientLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null contains Bridge Resources List Bridge.Resources.json
    2019-03-19T13:19:01:473 Trace Reading Bridge Resources List
    2019-03-19T13:19:01:474 Trace Read Bridge Resources List: [
    {
       "FileName": "ClientLibrary.js",
       "Name": "ClientLibrary.js",
       "Path": null,
       "Parts": null
    },
    {
       "FileName": "ClientLibrary.meta.js",
       "Name": "ClientLibrary.meta.js",
       "Path": null,
       "Parts": null
    }
    ]
    In a partial build, where ClientLibrary was not touched, I see the following in the trace logs:

    2019-03-19T13:21:37:715 Trace Checking if reference ClientLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null contains Bridge Resources List Bridge.Resources.json
    I have searched and searched and cannot find where Bridge.Resources.json is (or is supposed to be) stored on disk. What am I missing?

    Do you have any ideas on how to fix this?

    Thanks!

    Eric Hewitt
    Schweitzer Engineering Labs, Inc.
    Last edited by geoffrey.mcgill; 2019-03-22 @ 11:13 PM.

    #2
    Hi Eric,

    Thanks for the detailed post. We will investigate and respond back as soon as we can.

    Comment


      #3
      Hi Geoffrey,

      Have you had a chance to take a look at this? Any ideas/work-arounds?

      Thanks!

      Eric

      Comment


        #4
        Hi,

        I made a small investigation. First, Bridge.Resources.json and Bridge.Resources.list are assembly resources files. It is injected into the assembly by Bridge (it is like descriptors with list of generated files into the assembly).

        I created a solution with two class libraries (one references another), change the target file like you, rebuild the whole solution. After that, I changed a file of one project and press Ctrl-Shift-B. Only that project was built and the output folder contains resources from two projects.

        So, I guess, you need once whole solution rebuild (it is required to inject generated resources by Bridge). After that, the common build (Ctrl-Shift-B) should work correctly.

        Let me know if I misunderstood your scenario and your configuration (and Bridge behavior) is different.

        Comment


          #5
          Sorry for the late reply. I finally have a chance to get back to this. We were working on a major release.

          I followed your exact instruction, and indeed, it works exactly as you describe! Then I realized what the difference. The test projects are using the old .csproj format. We have converted all of our projects over to the new, dramatically simplified .csproj format.

          When I switched the two test projects to the new format, the problem I describe above appeared. For example, here is one of the project files:
          <Project Sdk="Microsoft.NET.Sdk">
            <PropertyGroup>
              <TargetFramework>net461</TargetFramework>
              <AssemblyName>BridgeBuildTime</AssemblyName>
            </PropertyGroup>
            <ItemGroup>
              <PackageReference Include="Bridge" Version="17.9.0" />
              <ProjectReference Include="..\BridgeDependency\BridgeDependency.csproj" />
            </ItemGroup>
          </Project>
          With the old format and zero code changes, the rebuild of two trivial projects takes milliseconds. With the new .csproj format, a rebuild with zero code changes takes about 3 seconds. It appears to take around 1.5 seconds per project, regardless of whether there were changes in the project.

          Comment

          Working...
          X