home.social

#msbuild — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #msbuild, aggregated by home.social.

fetched live
  1. i think #cmake deserves serious recognition for making a high level abstraction over both Linux build systems, and MSVC + (!) #msbuild. i know this is one of the purposes of having a cross-platform meta-build system to begin with, but it's easy to underestimate the difficulty of getting it into a format that works with the Visual Studio toolchain. it seems waaaayyyy more involved than just getting a Clang + #Ninja project to compile on Windows.

    with MSBuild, there is so much undocumented behavior to reverse engineer, concepts that don't cleanly match systems in the Makefile family. MSBuild is actually more of a declarative format with complex logic encoded in the vendored property and target files, rather than just having a self-contained set of rules. despite this, CMake seems to maintain good parity with MSBuild, e.g. with ARM64EC support

  2. i think #cmake deserves serious recognition for making a high level abstraction over both Linux build systems, and MSVC + (!) #msbuild. i know this is one of the purposes of having a cross-platform meta-build system to begin with, but it's easy to underestimate the difficulty of getting it into a format that works with the Visual Studio toolchain. it seems waaaayyyy more involved than just getting a Clang + #Ninja project to compile on Windows.

    with MSBuild, there is so much undocumented behavior to reverse engineer, concepts that don't cleanly match systems in the Makefile family. MSBuild is actually more of a declarative format with complex logic encoded in the vendored property and target files, rather than just having a self-contained set of rules. despite this, CMake seems to maintain good parity with MSBuild, e.g. with ARM64EC support

  3. i think #cmake deserves serious recognition for making a high level abstraction over both Linux build systems, and MSVC + (!) #msbuild. i know this is one of the purposes of having a cross-platform meta-build system to begin with, but it's easy to underestimate the difficulty of getting it into a format that works with the Visual Studio toolchain. it seems waaaayyyy more involved than just getting a Clang + #Ninja project to compile on Windows.

    with MSBuild, there is so much undocumented behavior to reverse engineer, concepts that don't cleanly match systems in the Makefile family. MSBuild is actually more of a declarative format with complex logic encoded in the vendored property and target files, rather than just having a self-contained set of rules. despite this, CMake seems to maintain good parity with MSBuild, e.g. with ARM64EC support

  4. i think #cmake deserves serious recognition for making a high level abstraction over both Linux build systems, and MSVC + (!) #msbuild. i know this is one of the purposes of having a cross-platform meta-build system to begin with, but it's easy to underestimate the difficulty of getting it into a format that works with the Visual Studio toolchain. it seems waaaayyyy more involved than just getting a Clang + #Ninja project to compile on Windows.

    with MSBuild, there is so much undocumented behavior to reverse engineer, concepts that don't cleanly match systems in the Makefile family. MSBuild is actually more of a declarative format with complex logic encoded in the vendored property and target files, rather than just having a self-contained set of rules. despite this, CMake seems to maintain good parity with MSBuild, e.g. with ARM64EC support

  5. i think #cmake deserves serious recognition for making a high level abstraction over both Linux build systems, and MSVC + (!) #msbuild. i know this is one of the purposes of having a cross-platform meta-build system to begin with, but it's easy to underestimate the difficulty of getting it into a format that works with the Visual Studio toolchain. it seems waaaayyyy more involved than just getting a Clang + #Ninja project to compile on Windows.

    with MSBuild, there is so much undocumented behavior to reverse engineer, concepts that don't cleanly match systems in the Makefile family. MSBuild is actually more of a declarative format with complex logic encoded in the vendored property and target files, rather than just having a self-contained set of rules. despite this, CMake seems to maintain good parity with MSBuild, e.g. with ARM64EC support

  6. MSBuild binlog viewer downloads have fallen off the cliff since ~March:

    msbuildlog.com/stats

    My interpretation is that AI is solving MSBuild issues, as well as less and less people using MSBuild. Also hopefully modern MSBuild and SDK is more pit of success.

    #msbuild #dotnet

  7. MSBuild binlog viewer downloads have fallen off the cliff since ~March:

    msbuildlog.com/stats

    My interpretation is that AI is solving MSBuild issues, as well as less and less people using MSBuild. Also hopefully modern MSBuild and SDK is more pit of success.

    #msbuild #dotnet

  8. MSBuild binlog viewer downloads have fallen off the cliff since ~March:

    msbuildlog.com/stats

    My interpretation is that AI is solving MSBuild issues, as well as less and less people using MSBuild. Also hopefully modern MSBuild and SDK is more pit of success.

    #msbuild #dotnet

  9. MSBuild binlog viewer downloads have fallen off the cliff since ~March:

    msbuildlog.com/stats

    My interpretation is that AI is solving MSBuild issues, as well as less and less people using MSBuild. Also hopefully modern MSBuild and SDK is more pit of success.

    #msbuild #dotnet

  10. MSBuild binlog viewer downloads have fallen off the cliff since ~March:

    msbuildlog.com/stats

    My interpretation is that AI is solving MSBuild issues, as well as less and less people using MSBuild. Also hopefully modern MSBuild and SDK is more pit of success.

    #msbuild #dotnet

  11. Over at @InfoWorld I took a look at some of the new developer tooling for Windows that Microsoft announced back at #msbuild: support for UNIX coreutils in Windows and new ways to quickly set up and manage developer workstations.

    infoworld.com/article/4188967/

  12. Over at @InfoWorld I took a look at some of the new developer tooling for Windows that Microsoft announced back at #msbuild: support for UNIX coreutils in Windows and new ways to quickly set up and manage developer workstations.

    infoworld.com/article/4188967/

  13. Over at @InfoWorld I took a look at some of the new developer tooling for Windows that Microsoft announced back at #msbuild: support for UNIX coreutils in Windows and new ways to quickly set up and manage developer workstations.

    infoworld.com/article/4188967/

  14. Over at @InfoWorld I took a look at some of the new developer tooling for Windows that Microsoft announced back at #msbuild: support for UNIX coreutils in Windows and new ways to quickly set up and manage developer workstations.

    infoworld.com/article/4188967/

  15. Over at @InfoWorld I took a look at some of the new developer tooling for Windows that Microsoft announced back at #msbuild: support for UNIX coreutils in Windows and new ways to quickly set up and manage developer workstations.

    infoworld.com/article/4188967/

  16. RE: hachyderm.io/@tmeschter/116751

    There's another option for getting information out of MSBuild that I didn't cover before because the thread was getting long: `-getTargetResult`.

    In MSBuild a target can (optionally) return a set of items. This lets you treat it as a function, not just a "unit of work".

    For example, you can run:
    `dotnet build -getTargetResult:ResolveReferences`

    and get
    ```
    {
    "TargetResults": {
    "ResolveReferences": {
    "Result": "Success",
    "Items": [
    {
    "Identity": "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Ref\\10.0.8\\ref\\net10.0\\Microsoft.CSharp.dll",
    "FileVersion": "10.0.826.23019",
    ...
    },
    {
    "Identity": "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Ref\\10.0.8\\ref\\net10.0\\Microsoft.VisualBasic.Core.dll",
    "FileVersion": "15.0.826.23019",
    ...
    },
    ...
    ]
    }
    }
    }
    ```
    which is a list of all the references being passed to the C# compiler, along with a bunch of metadata on each.

    Or you can run the "Build" target and get information about the outputs:
    ```
    > dotnet build -getTargetResult:Build
    {
    "TargetResults": {
    "Build": {
    "Result": "Success",
    "Items": [
    {
    "Identity": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\bin\\Debug\\net10.0\\TestConsole.dll",
    "ReferenceAssembly": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\obj\\Debug\\net10.0\\ref\\TestConsole.dll",
    "FullPath": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\bin\\Debug\\net10.0\\TestConsole.dll",
    ...
    }
    ]
    }
    }
    }
    ```

    So depending on the target that can be another option.

    #msbuild #dotnet #csharp

  17. RE: hachyderm.io/@tmeschter/116751

    There's another option for getting information out of MSBuild that I didn't cover before because the thread was getting long: `-getTargetResult`.

    In MSBuild a target can (optionally) return a set of items. This lets you treat it as a function, not just a "unit of work".

    For example, you can run:
    `dotnet build -getTargetResult:ResolveReferences`

    and get
    ```
    {
    "TargetResults": {
    "ResolveReferences": {
    "Result": "Success",
    "Items": [
    {
    "Identity": "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Ref\\10.0.8\\ref\\net10.0\\Microsoft.CSharp.dll",
    "FileVersion": "10.0.826.23019",
    ...
    },
    {
    "Identity": "C:\\Program Files\\dotnet\\packs\\Microsoft.NETCore.App.Ref\\10.0.8\\ref\\net10.0\\Microsoft.VisualBasic.Core.dll",
    "FileVersion": "15.0.826.23019",
    ...
    },
    ...
    ]
    }
    }
    }
    ```
    which is a list of all the references being passed to the C# compiler, along with a bunch of metadata on each.

    Or you can run the "Build" target and get information about the outputs:
    ```
    > dotnet build -getTargetResult:Build
    {
    "TargetResults": {
    "Build": {
    "Result": "Success",
    "Items": [
    {
    "Identity": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\bin\\Debug\\net10.0\\TestConsole.dll",
    "ReferenceAssembly": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\obj\\Debug\\net10.0\\ref\\TestConsole.dll",
    "FullPath": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\bin\\Debug\\net10.0\\TestConsole.dll",
    ...
    }
    ]
    }
    }
    }
    ```

    So depending on the target that can be another option.

    #msbuild #dotnet #csharp