Current situation

This buildpack builds a .Net app from source code using the dotnet publish command. It writes executable to the layers directory and then writes the location of the executable to the PUBLISH_OUTPUT_LOCATION env variable at build time so the dotnet execute buildpack will know where to run the app from.

Why this needs to change

This is a problem because it tightly couples this buildpack to any other downstream buildpack that would want to consume its output. Any consumer buildpack would need to both know about the environment variable and be able to use it at build time.

We attempted to have the Procfile buildpack consume the output of this buildpack to allow users to write their own start command, and found that it was impossible because the Procfile buildpack doesn't even run at build time, so it would have no way of consumer the environment variable.

Furthermore, every other buildpack runs the app from the workspace directory, so this breaks that pattern.

Proposed Solution

We should:.

1. Build the executable into some temporary directory.
2. Clear the workspace directory of the source code.
3. Place the executable and csproj file in the workspace directory.

We need to clear the workspace directory because otherwise the app executable will conflict with the source code directory, as documented here: #87

.NET 7 will be released in early November 2022.

To enable a quick release of .NET 7 in the buildpacks, we should create sample applications and integration tests for .NET 7 apps before the release. This can be done using a preview version of the .NET 7 dotnet CLI, as described in this exploration.

Describe the Enhancement

This build pack currently only supports discovering csproj, fsproj, and vbproj files (see source). Additionally, this build pack only detects the need for node/npm when it sees either referenced in a Target/Exec/Command XML element hierarchy (see source).

Microsoft / Visual Studio also has esproj files, which are used for JavaScript projects. esproj files also don't use a Target/Exec/Command structure because it's hidden behind the Microsoft.VisualStudio.JavaScript.Sdk SDK, and instead an esproj file looks like:

<Project Sdk="Microsoft.VisualStudio.JavaScript.Sdk/0.5.128-alpha">
  <PropertyGroup>
    <StartupCommand>npm run dev</StartupCommand>
    <JavaScriptTestRoot>src\</JavaScriptTestRoot>
    <JavaScriptTestFramework>Jest</JavaScriptTestFramework>
    <!-- Allows the build (or compile) script located on package.json to run on Build -->
    <ShouldRunBuildScript>false</ShouldRunBuildScript>
    <!-- Folder where production build objects will be placed -->
    <PublishAssetsDirectory>$(MSBuildProjectDirectory)\dist</PublishAssetsDirectory>
  </PropertyGroup>
</Project>

For reference of esproj files, please see:

• Property pages for React, Angular, and Vue projects in Visual Studio
• JavaScript and TypeScript in Visual Studio | Project templates
• MSBuild reference for the JavaScript Project System
• Tutorial: Create an ASP.NET Core app with React in Visual Studio

Possible Solutions

One, or a combination, of the following:

1. Look for esproj files in FindProjectFile

   A file extension by itself is not truly indicative of a dependency on node/npm, but fairly likely.

2. Look for usage of the Microsoft.VisualStudio.JavaScript.Sdk SDK in any project file?

   Usage of the SDK would be a better indicator of needing the node/npm commands.

3. Look for package.json files, similar to how the npm-install build pack detects its need (see source)?

   This may be a bit of a stretch for this build pack without a direct linkage to some .NET project / solution.

Motivation

With lack of support for esproj files, it requires developers to add unnecessary customizations to other project files in order for node/npm to be detected as being necessary and available during a build, similar to a MSBuild Target like what's in the Angular MSBuild .csproj file:

The current go.mod file references a github.com/cloudfoundry repo. Now that this repo lives in the paketo-buildpacks org, we should update the module name and the internal import statements in this codebase.

As a part of the .NET Core re-architecture, we should implement layer reuse in this buildpack so that dotnet publish is not run when there are no source code changes between builds

As part of the effort to remove .Net 2.1 from our fixture @sophiewigmore created READMEs for how to generate all of the apps that needed to be updated. I think that this was a brilliant idea and I would love to see documentation on how to generate the apps in all of our fixtures!

This is a break out issue to better track one of the optimization strategies laid out in issue #258.

Some context on the implementation of this strategy is present in the original issue however further tracking a progress for the reuse of incremental compilation data should be added to this issue!

What happened?

• What were you attempting to do?
  I was attempting to pack build this app.

pack build repro -b gcr.io/paketo-buildpacks/dotnet-core --verbose

• What did you expect to happen?
  It builds successfully (as it does with the previous version of the buildpack).

• What was the actual behavior? Please provide log output, if possible.
  Build fails with:

[builder] Paketo .NET Publish Buildpack 0.7.3
[builder]   Executing build process
[builder]     Running 'dotnet publish /workspace --configuration Release --runtime ubuntu.18.04-x64 --self-contained false --output /tmp/dotnet-publish-output2568415454'
[builder]
[builder]       Welcome to .NET 6.0!
[builder]       ---------------------
[builder]       SDK Version: 6.0.300
[builder]
[builder]       Telemetry
[builder]       ---------
[builder]       The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
[builder]
[builder]       Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
[builder]
[builder]       ----------------
[builder]       Installed an ASP.NET Core HTTPS development certificate.
[builder]       To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
[builder]       Learn about HTTPS: https://aka.ms/dotnet-https
[builder]       ----------------
[builder]       Write your first app: https://aka.ms/dotnet-hello-world
[builder]       Find out what's new: https://aka.ms/dotnet-whats-new
[builder]       Explore documentation: https://aka.ms/dotnet-docs
[builder]       Report issues and find source on GitHub: https://github.com/dotnet/core
[builder]       Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
[builder]       --------------------------------------------------------------------------------------
[builder]       Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
[builder]       Copyright (C) Microsoft Corporation. All rights reserved.
[builder]
[builder]         Determining projects to restore...
[builder]         Restored /workspace/Sample.csproj (in 8.32 sec).
[builder]         Sample -> /workspace/bin/Release/net6.0/ubuntu.18.04-x64/Sample.dll
[builder]         Sample -> /tmp/dotnet-publish-output2568415454/
[builder]       Completed in 12.412987681s
[builder]
[builder]   Dividing build output into layers to optimize cache reuse
[builder] decoding JSON to identify output slices: dependency runtime file malformed
[builder] ERROR: failed to build: exit status 1

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

 pack version
0.25.0+git-b9be13a.build-3254

• What buildpacks are you using? Please include versions.
  Paketo .NET Publish Buildpack 0.7.3

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
  N/A

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?
  https://github.com/sample-accelerators/steeltoe-weatherforecast/tree/tap-1.2/

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

See before and after packit rewrite. It seems like the new logic doesn't check for Microsoft.AspNetCore.App and Microsoft.AspNetCore.All. It seems to assume Microsoft.NET.Sdk.Web as sdk suffices the criterion. Could you investigate?

The buildpack contains a test which seems to validate building a self-contained app. Does this test actually need to be included in this buildpack? If so, is the app source for that test set up correctly? The source layout at this previous commit does not contain the output of dotnet publish whereas the most recent ones do (e.g. this commit). What is the intention of this test and the subsequent correct configuration of the test app?

The upstream Cloud Native Buildpacks project has a proposal to deprecate Buildpack APIs <= 0.6. This buildpack's API version will need to be upgraded so it remains supported by the lifecycle.

What happened?

• What were you attempting to do?

I wanted to see that Paketo buildpacks are up to date with the latest CNB Spec for buildpacks.

• What did you expect to happen?
  I expected to see that in the buildpack.toml for the buildpack, its API version was 0.5 since that's the latest release of the spec.

• What was the actual behavior? Please provide log output, if possible.
  The actual API version is 0.2 on the main branch of this repo (and in the latest release).

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

• What buildpacks are you using? Please include versions.

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Pivotal provides the GitBot service to synchronize pull requests and/or issues made against public GitHub repos with Pivotal Tracker projects. This service does not track individual commits.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request. An ask+cf@ ticket is the fastest way to get write access if you get a 404 to the config repo.

If you do not want have pull requests and/or issues copied from GitHub to Pivotal Tracker, you do not need to take any action.

If there are any questions, please reach out to [email protected].

Publish All Draft Releases workflow failed.

Summary

RFC0003 was approved. We should implement it.

Proposal

The build process of the dotnet-publish buildpack should be explicitly separated into 2 commands, dotnet restore and dotnet publish. Following this split, each command should be configurable using either the BP_DOTNET_RESTORE_FLAGS or BP_DOTNET_PUBLISH_FLAGS environment variables.

Summary

The current implementation allows a buildpack user to configure a project path using a buildpack.yml configuration file with the following contents:

dotnet-build:
  project-path: ./src/asp_web_app

After the approval of RFC0002 we should be preferring to allow that configuration via an environment variable like:

BP_DOTNET_PROJECT_PATH=./src/asp_web_app

Deprecation Notice

The buildpack should emit a deprecation notice via log output when a buildpack.yml file appears in the application source code with configuration for this buildpack. The deprecation notice should appear similar to notices that have been implemented in other buildpacks.

Background

The buildpack builds dll files with the dotnet publish command that are executed by the dotnet-core-conf buildpack.

Proposal

In order to conform the the restructure rfc, this buildpack should

• Be rewritten to be packit compliant
• Be renamed to dotnet-publish as that is a more descriptive name.

For now we should keep all functionality the same.

Note:

Make sure to go through the rest of the README's in the language family and change the references to theis buildpack to be correct.

This buildpack should include a test that confirms that offline vendoring of packages can be achieved.

You can vendor offline dependencies into your app by running the following command from within your source directory:

dotnet restore --packages ./packages --runtime ubuntu.18.04-x64

This will download all the packages for your app into the ./packages directory. You then need to configure NuGet to look only in this location to find packages. Create a nuget.config file with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <packageSources>
    <clear />
    <add key="app" value="./packages" />
 </packageSources>
</configuration>

You can then run a pack build with the --network flag set to none to confirm that the buildpack supports offline vendoring of packages.

What happened?

• What were you attempting to do?

I focused this integration test and turned off image + container cleanup so I could explore the app image.

• What did you expect to happen?

I expected to see a .dotnet_root directory in the /workspace, where the various dotnet dependencies are symlinked

• What was the actual behavior? Please provide log output, if possible.

I also saw another directory called .dotnet-root:

drwxr-xr-x 5 cnb  cnb    4096 Jan  1  1980 ./
drwxr-xr-x 1 root root   4096 Jan 19 23:07 ../
drwxr-xr-x 3 cnb  cnb    4096 Jan  1  1980 .dotnet-root/
drwxr-xr-x 3 cnb  cnb    4096 Jan  1  1980 .dotnet_root/

Where .dotnet-root contains:

drwxr-xr-x 3 cnb cnb   4096 Jan  1  1980 ./
drwxr-xr-x 5 cnb cnb   4096 Jan  1  1980 ../
-rwxr-xr-x 1 cnb cnb 105872 Jan  1  1980 dotnet*
lrwxrwxrwx 1 cnb cnb     62 Jan  1  1980 host -> /layers/paketo-buildpacks_dotnet-core-sdk/driver-symlinks/host/
lrwxrwxrwx 1 cnb cnb     56 Jan  1  1980 sdk -> /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk/sdk
drwxr-xr-x 2 cnb cnb   4096 Jan  1  1980 shared/

There should only be one .dotnet_root directory there, with all the necessary dependencies inside. I suspect this will make the RootManager unnecessary.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.
  Running scripts/integration.sh and having it install tooling versions.

• What buildpacks are you using? Please include versions.

Using commit 581572a of this repo

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
  N/A

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

To implement Paketo RFC0038, this buildpack will need to generate an SBOM for the packages that get installed via dotnet publish and store it in a CNB lifecycle-accessible file as outlined in the RFC.

Blocked

This issue is blocked on having some mechanism to actually generate an SBOM for a .NET Core app. Currently, we use the Syft library in packit in order to generate SBOMs for other buildpack language families, such as Node.js.

This issue is blocked on paketo-buildpacks/dotnet-core#712

anchore/syft#373 exists, which may be the most straightforward and logical place to approach solving this issue, so we can then consume the release and generate the BOM in a similar fashion to our other buildpacks. A reasonable starting place could be to consider how Syft could gather package info from the *.deps.json file after the publish step, or the obj/project.assets.json file.

Go get update workflow failed.
Please take a look to ensure CVE patches can be released. (cc @pivotal-cf/commercial-buildpacks).

Background

The buildpack currently requires itself on build, and dotnet-sdk, dotnet-runtime, node, dotnet-aspnetcore, and icu on build and launch.
It provides a built version of the application named dotnet-application in the form of a ready to go dll file.

Because this buildpack does not run the dll, it only builds it, it does not need to require any of these dependencies on launch, and it should never require itself.

Proposal

In order to conform the the restructure rfc, this buildpack should

Note that this buildpack will not specify the versions of any of the dependencies it requires. The dotnet-execute buildpack will be responsible for requesting all versions.

• Require the dotnet-runtime dependency on build.
• Require the dotnet-sdk dependency on build.
• Require the node dependency on build if it is needed. See logic here.
• Require the dotent-aspentcore dependency on build if it is needed. See logic here.
• Require the icu dependencies on build if it is needed. See logic here.

This buildpack should

• Provide the built dll file.

As a developer

I want to have the .NET buildpack detect and build when there are multiple module directories in the root of my git repo (e.g. src/module1, src/module2) that individually contain .csproj files

So that I can continue build my C# applications in a modular way that makes them more maintainable long term.

Approve bot PR workflow failed.

What happened?

• What were you attempting to do?

I wanted to build a .NET app that optimizes the size of its assemblies.

• What did you expect to happen?

I expected the buildpack to either a) automatically detect that the build should run with --self-contained=true or b) provide a config option that lets me specify that I want that flag set.

• What was the actual behavior? Please provide log output, if possible.

git clone [email protected]:fg-j/Blogifier.git
git co -b add-buildpack-config
pack build blogifier-demo --buildpack gcr.io/paketo-buildpacks/dotnet-core:0.1.1
...
...
...
Paketo .NET Publish Buildpack 0.1.3
  Executing build process
    Running 'dotnet publish /workspace/src/Blogifier --configuration Release --runtime ubuntu.18.04-x64 --self-contained false --output /tmp/dotnet-publish-output892641884'
      Failed after 3m0.1765225s

        Welcome to .NET 5.0!
        ---------------------
        SDK Version: 5.0.102

        Telemetry
        ---------
        The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

        Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

        ----------------
        Installed an ASP.NET Core HTTPS development certificate.
        To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
        Learn about HTTPS: https://aka.ms/dotnet-https
        ----------------
        Write your first app: https://aka.ms/dotnet-hello-world
        Find out what's new: https://aka.ms/dotnet-whats-new
        Explore documentation: https://aka.ms/dotnet-docs
        Report issues and find source on GitHub: https://github.com/dotnet/core
        Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
        --------------------------------------------------------------------------------------
        Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
        Copyright (C) Microsoft Corporation. All rights reserved.

          Determining projects to restore...
          Restored /workspace/src/Blogifier.Core/Blogifier.Core.csproj (in 1.36 min).
          Restored /workspace/src/Blogifier.Admin/Blogifier.Admin.csproj (in 1.58 min).
          Restored /workspace/src/Blogifier.Shared/Blogifier.Shared.csproj (in 50 ms).
          Restored /workspace/src/Blogifier/Blogifier.csproj (in 14.02 sec).
          Blogifier.Shared -> /workspace/src/Blogifier.Shared/bin/Release/net5.0/Blogifier.Shared.dll

          Bundler: Begin processing bundleconfig.json
          Bundler: Done processing bundleconfig.json
          Blogifier.Admin -> /workspace/src/Blogifier.Admin/bin/Release/net5.0/Blogifier.Admin.dll
          Blogifier.Admin (Blazor output) -> /workspace/src/Blogifier.Admin/bin/Release/net5.0/wwwroot
          Blogifier.Core -> /workspace/src/Blogifier.Core/bin/Release/net5.0/Blogifier.Core.dll
          Blogifier -> /workspace/src/Blogifier/bin/Release/net5.0/ubuntu.18.04-x64/Blogifier.dll
          Blogifier -> /workspace/src/Blogifier/bin/Release/net5.0/ubuntu.18.04-x64/Blogifier.Views.dll
        /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-core-sdk/sdk/5.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ILLink.targets(143,5): error NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. [/workspace/src/Blogifier.Admin/Blogifier.Admin.csproj]
failed to execute 'dotnet publish': exit status 1
ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle: failed with status code: 145

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

pack --version
0.17.0+git-d9cb4e7.build-2045

• What buildpacks are you using? Please include versions.

paketo-buildpacks/dotnet-core:0.1.1

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

See the add-buildpack-config branch of my fork of the Blogifier repo.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

What happened?

• What were you attempting to do?
  I was looking around at the fixtures to explore ways of setting up dotnet apps.

• What did you expect to happen?
  Given that buildpack.yml has been deprecated, I expected most of the fixtures to use a project.toml instead of a buildpack.yml.

• What was the actual behavior? Please provide log output, if possible.
  But many of the fixtures still rely on a buildpack.yml because the work to move dotnet-execute away from buildpack.yml isn't finished yet.

Once paketo-buildpacks/dotnet-execute#159 is merged and complete, the fixtures here should be updated to remove the buildpack.yml

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

• What buildpacks are you using? Please include versions.

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

As of #293, this buildpack is using packit v2 and streams logs from the dotnet publish command.

It would be helpful to also add debug logging capabilities to this buildpack to give users even more information about this build step when needed.

Describe the Enhancement

There should be a way to tell the buildpack not to delete certain parts of the source code in /workspace.

Possible Solution

Respect the environment variables that https://github.com/paketo-buildpacks/source-removal respects so that users can protect files from being removed.

Motivation

I was trying to build https://github.com/Squidex/squidex with the buildpack. The app has a frontend and backend that are designed to run in the same container. The Dockerfile multistage build transpiles the JavaScript frontend into static assets in a directory, and compiles the .NET backend into *.dlls.

I can't build this app with buildpacks because the dotnet-publish buildpack removes everything in the working directory besides the compiled app. My static assets get deleted if I build them before this buildpack runs, and the JavaScript source code gets deleted if I try to transpile it after this buildpack runs.

Reproduction Steps

Given an app that has the following directory structure:

├── buildpack.yml
└── console
    ├── Program.cs
    ├── console.csproj
    └── project.json

With the following file contents:

buildpack.yml

---
dotnet-build:
  project-path: "./console"

console/Program.cs

using System;

namespace console_app
{
    public class Program
    {
        public static void Main(string[] args)
        {
		Console.WriteLine("Hello World!");
                while(true){}
        }
    }
}

console/console.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <DebugType>portable</DebugType>
    <AssemblyName>console</AssemblyName>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Server.IISIntegration">
      <Version>*</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.AspNetCore.Server.Kestrel">
      <Version>*</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Extensions.Configuration.CommandLine">
      <Version>*</Version>
    </PackageReference>
  </ItemGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <DefineConstants>$(DefineConstants);RELEASE</DefineConstants>
  </PropertyGroup>
</Project>

console/project.json

{
  "buildOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.1"
    }
  },
  "frameworks": {
    "netcoreapp1.0": {
    }
  }
}

When I run pack build myapp --buildpack gcr.io/paketo-buildpacks/dotnet-core, the build fails and I see the following logs:

===> DETECTING
[detector] 5 of 7 buildpacks participating
[detector] paketo-buildpacks/icu                 0.0.97
[detector] paketo-buildpacks/dotnet-core-runtime 0.0.195
[detector] paketo-buildpacks/dotnet-core-sdk     0.0.192
[detector] paketo-buildpacks/dotnet-core-build   0.0.119
[detector] paketo-buildpacks/dotnet-core-conf    0.0.177
===> ANALYZING
[analyzer] Previous image with name "index.docker.io/library/myapp:latest" not found
===> RESTORING
===> BUILDING
[builder]
[builder] ICU Buildpack 0.0.97
[builder]    67.1.0: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/icu/icu_67.1.0_linux_noarch_any-stack_00267b03.tgz
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_icu/icu
[builder]
[builder] Paketo .NET Core Runtime Buildpack 0.0.195
[builder]    3.1.7: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/dotnet-runtime/dotnet-runtime_3.1.7_linux_x64_any-stack_52ccd274.tar.xz
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_dotnet-core-runtime/dotnet-runtime
[builder]     Writing DOTNET_ROOT to shared
[builder]     Writing RUNTIME_VERSION to build
[builder]
[builder] Paketo .NET SDK Buildpack 0.0.192
[builder]    3.1.401: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/dotnet-sdk/dotnet-sdk_3.1.401_linux_x64_any-stack_94ec0b48.tar.xz
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk
[builder]     Writing SDK_LOCATION to build
[builder]   Paketo .NET SDK Buildpack 0.0.192: Contributing to layer
[builder]     Symlinking runtime libraries
[builder]     Moving dotnet driver from /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk
[builder]     Writing PATH to shared
[builder]     Writing DOTNET_ROOT to shared
[builder]
[builder] Paketo .Net Build Buildpack 0.0.119
[builder]   : Contributing to layer
[builder]     Symlinking runtime libraries
[builder]     Moving dotnet driver from /layers/paketo-buildpacks_dotnet-core-sdk/driver-symlinks
[builder]     Symlinking the SDK from /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk
[builder]   : Contributing to layer
[builder]     Publishing source code
[builder]
[builder] Welcome to .NET Core 3.1!
[builder] ---------------------
[builder] SDK Version: 3.1.401
[builder]
[builder] Telemetry
[builder] ---------
[builder] The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
[builder]
[builder] Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
[builder]
[builder] ----------------
[builder] Explore documentation: https://aka.ms/dotnet-docs
[builder] Report issues and find source on GitHub: https://github.com/dotnet/core
[builder] Find out what's new: https://aka.ms/dotnet-whats-new
[builder] Learn about the installed HTTPS developer cert: https://aka.ms/aspnet-core-https
[builder] Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
[builder] Write your first app: https://aka.ms/first-net-core-app
[builder] --------------------------------------------------------------------------------------
[builder] Microsoft (R) Build Engine version 16.7.0-preview-20360-03+188921e2f for .NET
[builder] Copyright (C) Microsoft Corporation. All rights reserved.
[builder]
[builder]   Determining projects to restore...
[builder]   Restored /workspace/console/console.csproj (in 2.61 sec).
[builder]   console -> /workspace/console/bin/Release/netcoreapp3.1/ubuntu.18.04-x64/console.dll
[builder] /layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk/sdk/3.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Publish.targets(177,5): error MSB3024: Could not copy the file "/workspace/console/obj/Release/netcoreapp3.1/ubuntu.18.04-x64/console" to the destination file "/workspace/console", because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles. [/workspace/console/console.csproj]

The primary error seems to be this: error MSB3024: Could not copy the file "/workspace/console/obj/Release/netcoreapp3.1/ubuntu.18.04-x64/console" to the destination file "/workspace/console", because the destination is a folder instead of a file..

I believe that it is trying to build a Framework-Dependent Executable that is called console and then move that executable into /workspace. However, my source code already contains a directory called console which then creates a conflict and causes this error.

Proposal

We should consider building into a temporary directory or other location outside of the working directory to avoid these types of conflicts in the future.

As a developer

I want to be able to have the directory containing the csproj to have the same name as the csproj itself

So that I can follow a C# standard practice

Notes:
For some reason when the directory containing my csproj and the csproj itself have the same name I get the following error:

Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
  Determining projects to restore...
  Restored /workspace/module1/module1.csproj (in 157 ms).
  Restored /workspace/module2/module2.csproj (in 1.73 sec).
  module1 -> /workspace/module1/bin/Release/netcoreapp3.1/module1.dll
  module2 -> /workspace/module2/bin/Release/netcoreapp3.1/ubuntu.18.04-x64/module2.dll
/layers/paketo-buildpacks_dotnet-core-sdk/dotnet-sdk/sdk/3.1.302/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Publish.targets(177,5): error MSB3024: Could not copy the file "/workspace/module2/obj/Release/netcoreapp3.1/ubuntu.18.04-x64/module2" to the destination file "/workspace/module2", because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles. [/workspace/module2/module2.csproj]
exit status 1
ERROR: failed to build: exit status 103

Update GitHub config workflow failed.

This is a break out issue to better track one of the optimization strategies laid out in issue #258.

Some context on the implementation of this strategy is present in the original issue however further tracking a progress for the Nuget cache should be added to this issue!

We should implement RFC 27 in this buildpack. In particular, when BP_LOG_LEVEL=debug this buildpack should stream the logs from dotnet publish as they are happening, rather than storing them in a separate buffer. Debugging slow or hanging .NET builds is extremely challenging when the buildpack does not show dotnet publish logs until the command fails.

Push Buildpackage workflow failed.

Describe the Enhancement

Today, the buildpack can build .NET apps that include JavaScript frontends, like this integration test fixture. But the buildpack does not scan the node_modules that get installed when dotnet publish runs. So there's no way for me to know which node_modules are built into my frontend. Since this buildpack removes all the source code from the app working directory before it exits, there's no way to scan the node_modules after this buildpack has run. It would be great if the buildpack scanned the node_modules before removing the app's source code and put the resulting SBOM somewhere.

Possible Solution

After dotnet publish and before removing source code, use the existing scanning functionality in packit to scan the node_modules directory. To find the node_modules, explore the directory where the *proj file is located and any of its children. Attach it to the BuildMetadata.SBOM of the BuildResult since it's not associated with the contents of any layer.

Motivation

Not having an SBOM for node_modules means users and auditors can't check .NET + JavaScript apps for vulnerabilities in node_modules. Generating and storing this SBOM gives buildpack users more information about vulnerabilities than you'd get from scanning the end-result image.

What happened?

• What were you attempting to do?

Building and running an app image (console app) that contains a console.csproj file with <RuntimeFrameworkVersion>2.1.*</RuntimeFrameworkVersion> in it.

• What did you expect to happen?

The container to successfully run, using the versions specified by the buildpacks.

• What was the actual behavior? Please provide log output, if possible.

I used the dotnet-core v0.1.3 language family buildpack to build the app image. It selected dotnet-runtime version (using console.csproj): 2.1.25, the latest 2.1 version supported in the buildpack as expected.

Then, I ran docker run -it -p 8080:8080 console and it errored with:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.26' was not found.
  - Check application dependencies and target a framework version installed at:
      /workspace/.dotnet_root/
  - Installing .NET Core prerequisites might help resolve this problem:
      https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.25 at [/workspace/.dotnet_root/shared/Microsoft.NETCore.App]

When running the container, the error message shows that 2.1.26 is pulled in. This is pulled in by the .NET CLI itself, since that is the most current version available. When using the buildpacks, I would expect that the version the buildpack is pulling in would be the one that ends up on the image. We should find a way to avoid having the .NET CLI overruling the version selection.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

pack 0.17.0

• What buildpacks are you using? Please include versions.

dotnet-core v0.1.3

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Currently, the buildpack does not make any attempts to cache and reuse assets between builds. There are two main areas of improvement:

• NuGet packages: these are currently restored each time over the wire each time a build is run, which is very wasteful. Effort should be made to setup nuget cache and reuse it across builds
• Incremental compilation: obj folder that is implicitly created during the build process maintains a large number of artifacts. MSBuild uses it to do incremental builds, greatly speeding up the compilation of the same project between builds.

When running the pack command using the builder builder-jammy-full the publish is running with a runtime of ubuntu.18.04-x64. I have not confirmed this with other builders but that is the current observation.

Expected Behavior

Since running with builder-jammy-full, I would expect the runtime to change to reflect the correct runtime version as well.

Current Behavior

Running the pack command with --builder paketobuildpacks/builder-jammy-full results in a statement similar to the following: Running 'dotnet publish /workspace/***** --configuration Release --runtime ubuntu.18.04-x64 --self-contained false --output /tmp/dotnet-publish-output642231975'

Motivations

This has not resulted in any builds failing or any weirdness to this date but it is something that was observed today.

What happened?

Build a dotnet-core 5.0 application using buildpack with multiple submodules each with its own .csproj file and .sln file at the root.
Build fails with ERROR: No buildpack groups passed detection as it fails to locate project file in the root directory.

• What were you attempting to do?
  Build the application using .sln file instead of building each module individually.

• What did you expect to happen?
  Identify the dependencies through the .sln file and build the application

• What was the actual behavior? Please provide log output, if possible.
  Build fails with ERROR: No buildpack groups passed detection.
  

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.
  pack

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?
  paketobuildpacks/builder:base

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?
  https://github.com/dotnet-architecture/eShopOnWeb

Checklist

• [y] I have included log output.
• [y ] The log output includes an error message.
• [n ] I have included steps for reproduction.

Context

RFC 0005 outlines a plan for enabling Remote Debug support in the Paketo Buildpack for .NET Core. The implementation requires that .NET Core applications are compiled in a way that ensures debug support.

Required Changes

The dotnet-publish buildpack currently runs the following command in its build process:

dotnet publish \
  --configuration Release \
  --runtime ubuntu.18.04-x64 \
  --self-contained false \
  --output <output-path>

When the BP_DEBUG_ENABLED environment variable is set to true, the buildpack will set the --configuration flag to Debug to ensure debug support is built into the compiled application.

Criteria for Acceptance

When the BP_DEBUG_ENABLED environment variable is set to true:

• I should see in the build output that dotnet publish is run with --configuration Debug and NOT --configuration Release.

Create Draft Release workflow failed.