Announcement

Collapse
No announcement yet.

Minimal Bridge template error using dotnet CLI

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

    Minimal Bridge template error using dotnet CLI

    The goal:
    • minimal Bridge template
    • uses latest csproj format (to gain Omnisharp features in vscode)
    • can restore/build from command line

    What I tried:​​​​​​
    1. Install VSCode and Bridge globally (command line tools bridge and dotnet are available).
    2. Create empty folder, open command prompt in that folder.
    3. Run dotnet new classlib.
    4. Edit generated csproj file and change target framework from netstandard2.0 to net472 (since Bridge doesn't target netstandard as far as I can tell, and instead expects the the regular .NET Framework)
    5. Run dotnet restore. No errors occur.
    6. Run dotnet build. The following error occurs:
    Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
    Copyright (C) Microsoft Corporation. All rights reserved.

    Restore completed in 38 ms for C:\Users\caleb\Desktop\Test\Test.csproj.
    Test -> C:\Users\caleb\Desktop\Test\bin\Debug\net472\Test. dll
    Bridge started
    C:\Users\caleb\.nuget\packages\bridge.min\17.3.0\b uild\Bridge.Min.targets(25,5): error MSB4062: The "BridgeCompilerTask" task could not be loaded from the assembly C:\Users\caleb\.nuget\packages\bridge.min\17.3.0\b uild\..\tools\Bridge.Builder.v17.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\caleb\Desktop\Test\Test.csproj]

    Build FAILED.

    C:\Users\caleb\.nuget\packages\bridge.min\17.3.0\b uild\Bridge.Min.targets(25,5): error MSB4062: The "BridgeCompilerTask" task could not be loaded from the assembly C:\Users\caleb\.nuget\packages\bridge.min\17.3.0\b uild\..\tools\Bridge.Builder.v17.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\caleb\Desktop\Test\Test.csproj]
    0 Warning(s)
    1 Error(s)

    Time Elapsed 00:00:01.15
    What is interesting is that Visual Studio 2017 has no problem building this project as configured above:

    ------ Rebuild All started: Project: Test, Configuration: Debug Any CPU ------
    Test -> C:\Users\caleb\Desktop\Test\bin\Debug\net472\Test. dll
    Bridge started
    Bridge config file is not found. Returning default config
    To enable detailed logging, configure "logging" in bridge.json.
    https://github.com/bridgedotnet/Brid...ration#logging
    Bridge done
    ------ Rebuild All started: Project: Test, Configuration: Release Any CPU ------
    Test -> C:\Users\caleb\Desktop\Test\bin\Release\net472\Tes t.dll
    Bridge started
    Bridge config file is not found. Returning default config
    To enable detailed logging, configure "logging" in bridge.json.
    https://github.com/bridgedotnet/Brid...ration#logging
    Bridge done
    ========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
    This seems to be related to the fact that Visual Studio 2017 does not use the same build chain as the dotnet CLI as mentioned here: https://github.com/dotnet/cli/issues/6032

    Does this mean that I should try to use msbuild instead of dotnet? Am I missing something in my setup in order to get Bridge to work properly with the new csproj format?

    Here is a link to a Gist of the example code that reproduces the error: https://gist.github.com/SirUppyPanca...912b2a4135e1ef

    #2
    Just experimented with using msbuild, and this works very well:
    1. Installing Build Tools for Visual Studio 2017 from here: https://visualstudio.microsoft.com/downloads/ (under the Tools for Visual Studio 2017 section)
    2. Using a helper to locate msbuild in a script (in my case I use batch files for most things): https://github.com/3F/hMSBuild
    3. You can then build/clean/rebuild or run any other msbuild target with a script like this:
    msbuild.bat
    @echo off >nul 2>&1
    dotnet restore
    hmsbuild.bat Test.csproj /t:%1
    This will restore packages and run the target of your choice from the command line (eg: ./msbuild rebuild).

    I'll still be interested in finding out if it's possible to get the dotnet CLI working with a project file like this, but this is more than an acceptable work-around for the time being.

    Comment


      #3
      Hello @SirUppyPancakes!

      Thanks for sharing your experience using Bridge with the dotnet CLI. And yes, Bridge has been using just msbuild, we haven't really focused on the dotnet CLI to build Bridge projects, so it would be quite possible for missing libraries (even though we try to add most of the likely libraries to be missing into the Bridge.Min libraries directory).

      The interesting thing is that we do include both Microsoft.Build.Framework.dll and Microsoft.Build.Utilities.Core.dll files in Bridge.Min package. So probably it wanted another version of the file that's actually present (packages/Bridge.Min.17.3.0/tools/). Or maybe for some reason in the dotnet core environment, it is not looking at the same directory where the Bridge.Builder.v17.dll file is for the other DLL files for matches.

      I believe you can just play around the MSBuild library files present after you installed the build tools for vs 2017, copying over the file in the Bridge.Min.17.3.0/tools, if that's just the version that's wrong, then just adding the missing (or correct version) DLL in the Bridge.Min directory should do.

      Hope this helps!

      Comment


        #4
        Thanks for the info!

        I had forgotten to post the result of running bridge build as well, which produces the following error (it gets a bit cut off at the start by the console buffer):

        C:\Users\caleb\Desktop\Test>bridge build
        Defaulting Project Location to C:\Users\caleb\Desktop\Test\Test.csproj
        Building Test \
        C:\Users\caleb\Desktop\Test>oft.Build.Exceptions.I nvalidProjectFileException: Invalid static method invocation syntax
        : "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIden tifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget), $(TargetFrameworkRootPath), $(TargetFrameworkFallbackSearchPaths))". Method 'Microsoft.Build.Utilities.ToolLocationHelper.GetP athToStandardLibraries' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)). C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsof t.Common.CurrentVersion.targets
        at Microsoft.Build.Shared.ProjectErrorUtilities.Throw InvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
        at Microsoft.Build.Shared.ProjectErrorUtilities.Throw InvalidProject[T1,T2](IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1)
        at Microsoft.Build.Evaluation.Expander`2.Function`1.E xecute(Object objectInstance, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation)
        at Microsoft.Build.Evaluation.Expander`2.PropertyExpa nder`1.ExpandPropertyBody(String propertyBody, Object propertyValue, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
        at Microsoft.Build.Evaluation.Expander`2.PropertyExpa nder`1.ExpandPropertiesLeaveTypedAndEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
        at Microsoft.Build.Evaluation.Expander`2.PropertyExpa nder`1.ExpandPropertiesLeaveEscaped(String expression, IPropertyProvider`1 properties, ExpanderOptions options, IElementLocation elementLocation, UsedUninitializedProperties usedUninitializedProperties)
        at Microsoft.Build.Evaluation.Expander`2.ExpandIntoSt ringLeaveEscaped(String expression, ExpanderOptions options, IElementLocation elementLocation)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePro pertyElement(ProjectPropertyElement propertyElement)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluatePro pertyGroupElement(ProjectPropertyGroupElement propertyGroupElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImp ortElement(String directoryOfImportingFile, ProjectImportElement importElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImp ortElement(String directoryOfImportingFile, ProjectImportElement importElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImp ortElement(String directoryOfImportingFile, ProjectImportElement importElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImp ortElement(String directoryOfImportingFile, ProjectImportElement importElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImp ortElement(String directoryOfImportingFile, ProjectImportElement importElement)
        at Microsoft.Build.Evaluation.Evaluator`4.PerformDept hFirstPass(ProjectRootElement currentProjectOrImport)
        at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IL oggingService loggingService, BuildEventContext buildEventContext)
        at Microsoft.Build.Evaluation.Project.Reevaluate(ILog gingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
        at Microsoft.Build.Evaluation.Project.ReevaluateIfNec essary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings)
        at Microsoft.Build.Evaluation.Project.ReevaluateIfNec essary(EvaluationContext evaluationContext)
        at Microsoft.Build.Evaluation.Project.Initialize(IDic tionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
        at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
        at Bridge.Translator.Translator.EnsureProjectProperti es()
        at Bridge.Translator.TranslatorProcessor.SetTranslato rProperties()
        at Bridge.Translator.TranslatorProcessor.PreProcess()
        at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoi d1[T0](CallSite site, T0 arg0)
        at Bridge.CLI.Program.Main(String[] args)
        Any thoughts on the above error? I had initially switched to investigating the dotnet CLI error instead of this one because it was a little easier to search online.

        Ultimately it would be nice to be able to simply call bridge build rather than msbuild directly, but it's definitely not a blocking issue.

        If this looks like some sort of bug, let me know and I'll create an issue for it on GitHub.

        Btw, loving Bridge so far!

        Comment


          #5
          What I can see in that is that the wrong Microsoft.Build.Utilities library is being loaded.

          I was experimenting with this some time ago, and it was pretty difficult to make Bridge favor the library versions within its own tools folder than system's, and in some situations it was loading the wrong version and errors like this could potentially occur.

          Clearly yours is referencing a version of MS Build utilities where the Microsoft.Build.Utilities.ToolLocationHelper.GetPathToStandardLibraries() method signature doesn't match the one used by Bridge.

          I see you targeted frameworks not the legacy .NET Framework 4.x, but the newer netcore/netstandard. The support for new csproj format, despite being present, does not mean it will support the netcore/standard targets without some changes.

          There's also the issue that Bridge as currently is called by a msbuild task -- which may not be really compatible (unless it calls msbuild) from the dotnet client. Alternatively, the bridge builder console application (not Bridge CLI) can be called to replace the msbuild task. You can see what I'm talking about if you check the C:\Users\caleb\.nuget\packages\bridge.min\17.3.0\b uild\Bridge.Min.targets file (extracted from your error output). There will also be the command it calls where the msbuild task is not supported. It used to be true on Mono 4.x environment, but since Mono 5 was released, msbuild became possible under non-windows environments as well and msbuild tasks could be triggered from Mono.

          Sorry there's not really an "easy fix", the probable pragmatic solution would be to get rid of different versions of libraries from the system, but that's far from okay. An actual "fix" for this would be probably better assembly handling from Translator's InspectAssembly, assembly resolver.

          I hope this helps!

          Comment


            #6
            Thanks, makes sense.

            I think the current workaround I am using should be fine for now.

            Comment

            Working...
            X