profile
viewpoint

nil4/dotnet-transform-xdt 114

Modern .NET tools and library for XDT (Xml Document Transformation)

nil4/xdt-samples 10

XDT (XML Document Transformation) samples for .NET Core/ASP.NET Core

nil4/ANCM-AnyApp 1

Demo/test for https://github.com/nil4/IISIntegration

nil4/AspNetCore 0

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.

nil4/cyclonedx-dotnet 0

Creates CycloneDX Software Bill of Materials (SBOM) from .NET Projects

nil4/hide-vs-menu 0

Hide Visual Studio menu bar until `Alt` is pressed

nil4/hide-vs-wastebar 0

Hide VS 2019 (16.1 and later) space-wasting top toolbar

nil4/IISIntegration 0

ASP.NET Core IIS integration (+Docker)

nil4/WebPackTaskRunner 0

A Visual Studio extension

issue openedangular/angular

Angular 13 support dates missing on angular.io

Description

Please update the release support policy and schedule section (https://angular.io/guide/releases#support-policy-and-schedule) on angular.io to list support dates for Angular 13.

What is the affected URL?

https://angular.io/guide/releases#support-policy-and-schedule

Please provide the steps to reproduce the issue

No response

Please provide the expected behavior vs the actual behavior you encountered

Per the blog announcement (https://blog.angular.io/angular-v13-is-now-available-cce66f7bc296), Angular 13 was released on November 4, 2021. However, the support dates for this version are not listed on angular.io.

Please provide a screenshot if possible

No response

Please provide the exception or error you saw

No response

Is this a browser-specific issue? If so, please specify the device, browser, and version.

No response

created time in 24 days

pull request commentwixtoolset/VisualStudioExtension

Add support for VS2022

@drolevar I really appreciate your work on getting Votive ready for VS 2022!

I managed to build the Votive2022 VSIX using your instructions above https://github.com/wixtoolset/VisualStudioExtension/pull/21#issuecomment-941993603, and can confirm it installs and works.

While building, I did run into one minor issue, related to https://github.com/drolevar/VisualStudioExtension/blob/f07ba11fa5a1c6fd98a65957468e78a6c7d12964/tools/WixBuild.Tools.targets#L16. This reference to Microsoft.Build.Tasks version 2.0 appears to be a .NET 2.0 / 3.5 assembly.

On Windows 11, with only VS 2022 RC2 installed, .the NET Framework 3.5 OS feature is not enabled by default, and the reference cannot be resolved. Updating it to the equivalent MSBuild 17.0 task assembly seemed to do the trick, and allowed the Votive build to succeed:

-<UsingTask TaskName="AssignTargetPath" AssemblyName="Microsoft.Build.Tasks, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
+<UsingTask TaskName="AssignTargetPath" AssemblyName="Microsoft.Build.Tasks.Core, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

I hope this might help others who run into this.

drolevar

comment created time in a month

issue commentDependencyTrack/dependency-track

Non-deterministic output from `api/v1/component/identity`

@stevespringett I really appreciate the quick response and solution suggested here.

To test this, I started with the v4.3.6 source, applied the changes in the two commits (https://github.com/DependencyTrack/dependency-track/commit/adb8c9e4a1d30f5046ed4ba35296f000945fb038 and https://github.com/DependencyTrack/dependency-track/commit/dc1065930fe0c9047ad4810127967638edf98de9) to it, and then rebuilt the bundled jar using:

mvn package -Dmaven.test.skip=true -P embedded-jetty -P bundle-ui -Dlogback.configuration.file=src/main/docker/logback.xml

Unfortunately the issue still persisted.

To verify that it is not specific to the existing instance (e.g. environment, host or DB), I spun up a separate DT instance on a different machine with a new and empty SQL Server 2019 database, and let it run overnight to retrieve advisories and update portfolio metrics.

The issue was also reproducible on the second instance. Here, I was able to run SQL Server Profiler to review the DB queries executed when the API call was made (/api/v1/component/identity?purl=pkg:npm/%40angular/core@&sortOrder=asc&pageSize=25&pageNumber=1):

exec sp_executesql N'SELECT ''org.dependencytrack.model.Component'' AS DN_TYPE,A0.AUTHOR,A0.BLAKE2B_256,A0.BLAKE2B_384,A0.BLAKE2B_512,A0.BLAKE3,A0.CLASSIFIER,A0.COPYRIGHT,A0.CPE,A0.DESCRIPTION,A0.DIRECT_DEPENDENCIES,A0.EXTENSION,A0.FILENAME,A0."GROUP",A0.ID AS NUCORDER0,A0.INTERNAL,A0.LAST_RISKSCORE,A0.LICENSE,A0.MD5,A0."NAME",A0.TEXT,B0.ACTIVE,B0.AUTHOR,B0.CLASSIFIER,B0.CPE,B0.DESCRIPTION,B0.DIRECT_DEPENDENCIES,B0."GROUP",B0.ID,B0.LAST_BOM_IMPORTED,B0.LAST_BOM_IMPORTED_FORMAT,B0.LAST_RISKSCORE,B0."NAME",B0.PUBLISHER,B0.PURL,B0.SWIDTAGID,B0.UUID,B0.VERSION,A0.PUBLISHER,A0.PURL,A0.PURLCOORDINATES,C0.FSFLIBRE,C0.ID,C0.LICENSEID,C0."NAME",C0.ISOSIAPPROVED,C0.UUID,A0.SHA1,A0.SHA_256,A0.SHA_384,A0.SHA3_256,A0.SHA3_384,A0.SHA3_512,A0.SHA_512,A0.SWIDTAGID,A0.UUID,A0.VERSION FROM COMPONENT A0 INNER JOIN PROJECT B0 ON A0.PROJECT_ID = B0.ID LEFT OUTER JOIN LICENSE C0 ON A0.LICENSE_ID = C0.ID WHERE LOWER(A0.PURL) LIKE ''%pkg:npm/\%40angular/core@%'' ESCAPE ''\'' ORDER BY NUCORDER0 OFFSET 0 ROWS FETCH NEXT 25 ROWS ONLY '

Running this query independently on both DT instances' databases, I could verify that project-related fields (e.g. B0.UUID, B0.Name, B0.Version and B0.Active) are correctly populated every time, for every component in each result set.

Therefore, the SQL search results appear to be correct, and the issue may be internal to DT API code. Unfortunately, I am not a Java developer so I don't have the expertise to debug further into the DT code. I do hope that this information might help narrow down the root cause further.

nil4

comment created time in a month

issue openeddotnet/format

`dotnet format` without arguments - show usage instead of stack trace

Today I learned that dotnet format is included with .NET 6.0 SDK, so I ran dotnet format, hoping to find out which arguments it expects:

> dotnet --version
6.0.100-rc.2.21505.57

> dotnet format

Observed results

Red stack trace text filled the console window, scrolling the point it was trying to make with the first line of output off the screen:

> dotnet format
Unhandled exception: System.IO.FileNotFoundException: Could not find a MSBuild project file or solution file in 'C:\some\path'. Specify which to use with the <workspace> argument.
   at Microsoft.CodeAnalysis.Tools.Workspaces.MSBuildWorkspaceFinder.FindWorkspace(String searchDirectory, String workspacePath)
   at Microsoft.CodeAnalysis.Tools.Workspaces.MSBuildWorkspaceFinder.FindWorkspace(String searchDirectory, String workspacePath)
   at Microsoft.CodeAnalysis.Tools.FormatCommandCommon.ParseWorkspaceOptions(ParseResult parseResult, FormatOptions formatOptions)
   at Microsoft.CodeAnalysis.Tools.Commands.RootFormatCommand.FormatCommandDefaultHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass27_0.<<UseVersionOption>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__24_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseDebugDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

Expected results

The tool should display some concise guidance for the user. Stack traces can be useful when there's an actual catastrophic error, but not so great for missing arguments.

It would be nice to see, for instance, just this (minus the stack trace):

> dotnet format
Could not find a MSBuild project file or solution file in 'C:\some\path'. 
Specify which to use with the <workspace> argument.

Or perhaps to fall back to something like dotnet format --help:

> dotnet format
Usage:
  dotnet-format [options] [<The project or solution file to operate on. If a file is not specified, the command will
  search the current directory for one.>] [command]

Arguments:
  <The project or solution file to operate on. If a file is   The project or solution file to operate on. If a file is
  not specified, the command will search the current          not specified, the command will search the current
  directory for one.>                                         directory for one. [default: C:\some\path\]

Options: [... etc ...]

created time in a month

issue openedDependencyTrack/dependency-track

Non-deterministic output from `api/v1/component/identity`

The api/v1/component/identity endpoint returns non-deterministic results with respect to the projects that a component appears in. Specifically, for some (but not all) of the components returned, the project details are missing or incomplete. Furthermore, the set of which components are affected by this is changing over time, even when no new SBOMs have been uploaded in the meantime.

This is observable from the Dependency Track front-end by searching for components by PURL at /components, and also reproducible by calling the API directly.

Steps to Reproduce:

In the Dependency Track front-end, open the /components page and search by PURL for components present in multiple projects. (I'll use pkg:npm/%40angular/core@ as a concrete example below.)

In the browser console, inspect the response to the underlying DT API, /api/v1/component/identity?purl=pkg:npm/%40angular/core@&sortOrder=asc&pageSize=10&pageNumber=1. Alternatively, call the API directly and inspect the response.

Expected Behavior:

The API response is consistent in structure and over time. That is, every returned component includes a fully-populated project field, including project UUID, name, etc.). Separate API calls, when performed at various points in time, return consistent results.

Current Behavior:

The API responses are inconsistent in structure. For some (but not all) of the components returned, the project details are missing or incomplete. For example:

{
    "group": "@angular",
    "name": "core",
    "version": "11.2.3",
    "classifier": "LIBRARY",
    "sha512": "f86eeb663db531c99fea75a343bf44c289b010e550d562eac3a62f0975b3809f599558cb8bf4ad8b4fe323352980ad04d059fceb2b97c3fbe062ae648c678e71",
    "purl": "pkg:npm/%40angular/core@11.2.3",
    "purlCoordinates": "pkg:npm/%40angular/core@11.2.3",
    "description": "Angular - the core framework",
    "resolvedLicense": {/*elided*/},
    "project": {
        "active": true
    },
    "lastInheritedRiskScore": 0.0,
    "uuid": "1e10a5e8-3857-43f6-a355-fdb4da35362b",
    "metrics": {/*elided*/},
    "repositoryMeta": {
        "repositoryType": "NPM",
        "namespace": "@angular",
        "name": "core",
        "latestVersion": "12.2.10",
        "lastCheck": 1634261643706
    },
    "usedBy": 0,
    "isInternal": false
}

Note that project has no UUID or name (yet is active), and usedBy is 0, i.e. it appears that this component is not used by any projects.

Some time later, however, or after triggering the portfolio metrics update task, this changes. Although no SBOMs have been uploaded and thus components/projects remained the same, a later call to the API returns a different set of components whose project details are missing.

Repeat the API call again, after some more time passes, and the result changes again.

Environment:

  • Dependency-Track Version: 4.3.6
  • Distribution: Executable WAR
  • BOM Format & Version: CycloneDX 1.3
  • Database Server: MSSQL
  • Browser: N/A (any)

Additional Details:

We use this Dependency Track API to track certain components, for example for compliance with official support timelines, and notify project owners of any changes. Due to the API results being non-deterministic over time, the attribution of issues detected to the affected projects is unstable and triggers a lot of false-positives.

A few recent screenshots are provided below to hopefully illustrate the issue more clearly.

Search results as of Oct 14 at 16:13:

angular-Oct-14@16_13-REDACTED

No SBOMs have been uploaded in the meantime, but the search results as of Oct 15 at 08:55 changed:

angular-Oct-15@08-55-REDACTED

A manual portfolio metrics update task was requested a bit later. It ran for about 50 minutes, with the condensed log:

09:09:32.539 INFO [MetricsUpdateTask] Executing portfolio metrics update
09:09:32.539 INFO [MetricsUpdateTask] Executing metrics update on vulnerability database
09:09:32.554 INFO [MetricsUpdateTask] Executing metrics update for project: 9bac92a1-3b1d-4230-9c0f-56a9f24f472a
09:09:36.699 INFO [MetricsUpdateTask] Completed metrics update for project: 9bac92a1-3b1d-4230-9c0f-56a9f24f472a
[...]
09:55:57.307 INFO [MetricsUpdateTask] Completed metrics update for project: 5d3ad25e-296b-4d74-a537-994178111576
09:55:57.307 INFO [MetricsUpdateTask] Executing metrics update for project: 0230d460-ec95-4040-a6d5-889d6d03c4f3
09:55:57.744 INFO [MetricsUpdateTask] Completed metrics update for project: 0230d460-ec95-4040-a6d5-889d6d03c4f3
09:55:57.838 INFO [MetricsUpdateTask] Completed portfolio metrics update

Thereafter, around Oct 15 at 09:58 the search results have changed again:

angular-Oct-15@09-58-REDACTED

created time in a month

issue commentCycloneDX/cyclonedx-cli

`merge`-d polyglot SBOM loses dependency graph information

Upon further testing, the issue is also apparent when merging SBOMs where each includes dependency graph information.

For example, merge two .NET project SBOMs:

mkdir src\csharp1 && pushd src\csharp1
dotnet new console
dotnet add package Serilog.Sinks.File
dotnet cyclonedx -ns -dgl -o . csharp1.csproj
popd

mkdir src\csharp2 && pushd src\csharp2
dotnet new console
dotnet add package jQuery
dotnet cyclonedx -ns -dgl -o . csharp2.csproj
popd

cyclonedx-win-x64 merge --input-files src\csharp1\bom.xml src\csharp2\bom.xml --output-file src\bom-merged.xml

When bom-merged.xml is uploaded to Dependency Track, the dependency graph is lost:

image

nil4

comment created time in 2 months

issue openedCycloneDX/cyclonedx-cli

`Merge`-d polyglot SBOM loses dependency graph information

Problem overview

CycloneDX tools vary in their support for dependency graph information. For example, cyclonedx-dotnet@0.19.0 supports it, while cyclonedx-node-module does not due to https://github.com/CycloneDX/cyclonedx-node-module/issues/61.

When merging SBOMs in a polyglot project, such that one or more SBOMs have dependency graph information, the output should ideally preserve that, but it currently does not.

To demonstrate this, two projects will be created: one .NET (dependency graph supported) and one NPM (no dependency graph). Their SBOMs, when uploaded individually to Dependency Track, correctly reflect the dependency graph information, if present.

The two SBOMs are then merge-d and the output uploaded. The expectation is that the merged SBOM preserves the input files' dependency graph information, whereas it currently seems to be lost.

Steps to reproduce

Create a simple .NET project and collect its SBOM:

> dotnet --version
5.0.401

> dotnet cyclonedx --version
2.1.2.0

> mkdir src\csharp && pushd src\csharp

src\csharp> dotnet new console
The template "Console Application" was created successfully.

src\csharp> dotnet add package Serilog.Sinks.File 
info : PackageReference for package 'Serilog.Sinks.File' version '5.0.0' added to file 'src\csharp\csharp.csproj'.
info : Writing assets file to disk. Path: src\csharp\obj\project.assets.json
log  : Restored src\csharp\csharp.csproj (in 67 ms).

src\csharp> dotnet cyclonedx -ns -dgl -o .. csharp.csproj 
» Analyzing: src\csharp\csharp.csproj
  Attempting to restore packages
Retrieving Serilog 2.10.0
Retrieving Serilog.Sinks.File 5.0.0

Creating CycloneDX BOM
Writing to: src\bom.xml

Upload src\bom.xml to Dependency Track v4.3.6, confirming that the dependency graph information of the .NET project is present, as expected:

image

Next, create a simple NPM project and collect its SBOM:

> npm --version 
8.0.0

> cyclonedx-bom --version
3.1.1

> mkdir src\js && pushd src\js

src\js> npm init -y
Wrote to src\js\package.json

src\js> npm install jquery --save-dev
added 1 package, and audited 2 packages in 1s
found 0 vulnerabilities

src\js> cyclonedx-bom -ns -d -o ..\bom-js.xml .

Upload src\bom-js.xml to Dependency Track; no dependency graph information is present, and this is expected per https://github.com/CycloneDX/cyclonedx-node-module/issues/61:

image

Finally, merge the individual files into a polyglot SBOM:

> cyclonedx-win-x64 --version
0.19.0

> cyclonedx-win-x64 merge --input-files src\bom.xml src\bom-js.xml --output-file src\bom-polyglot.xml
Processing input file src\bom.xml
    Contains 2 components
Processing input file src\bom-js.xml
    Contains 1 components
Writing output file...
    Total 3 components

Upload src\bom-polyglot.xml to Dependency Track.

Expected results

The dependency graph information present in the input files (e.g. src\bom.xml) is preserved in a merge-d polyglot SBOM.

Observed results

Three components are present (as expected), however the dependency graph information is lost:

image

created time in 2 months

PR opened CycloneDX/cyclonedx-dotnet

Avoid `NullReferenceException` for packages with no dependencies

As reported in https://github.com/CycloneDX/cyclonedx-dotnet/issues/436, attempts to iterate over package.Dependencies can lead to NullReferenceException if a package has no dependencies:

https://github.com/CycloneDX/cyclonedx-dotnet/blob/929544857c86d25ee4248963e7308dd0d287636f/CycloneDX/Program.cs#L273

This PR protects against the issue by substituting an empty dependency set whenever package.Dependencies is null. Testing locally, this resolved the original issue and unit tests pass.

Fixes #436.

+4 -2

0 comment

1 changed file

pr created time in 2 months

push eventnil4/cyclonedx-dotnet

nil4

commit sha b1351c30abe5f66e3ee39bc01ad462161ab7b359

Avoid `NullReferenceException` for packages with no dependencies Fixes https://github.com/CycloneDX/cyclonedx-dotnet/issues/436

view details

push time in 2 months

fork nil4/cyclonedx-dotnet

Creates CycloneDX Software Bill of Materials (SBOM) from .NET Projects

https://cyclonedx.org/

fork in 2 months

issue openedCycloneDX/cyclonedx-cli

`merge` output includes UTF-8 byte-order-marks

After upgrading cyclonedx-cli from v0.16.0 to v0.19.0, it was observed that XML BOMs produced by the merge command started being rejected when uploaded to Dependency Track v4.3.6.

The issue is that cyclonedx-cli merge now produces XML BOM files with UTF-8 byte-order-marks, unlike the earlier version, and Dependency Track rejects such files as invalid. Arguably, that's a DT bug, reported separately (https://github.com/DependencyTrack/dependency-track/issues/1214)

Steps to reproduce

Merge two XML BOM files using cyclonedx-cli v0.19.0 and 0.16.0, respectively, and compare the outputs. The two files are identical, except for the UTF-8 byte-order-mark present in the later version.

The attached ZIP file includes sample input (bom1.xml and bom2.xml) and output files: merge-sample-with-byte-order-mark.zip

> cyclonedx-win-x64 --version
0.16.0
> cyclonedx-win-x64 merge --input-files bom1.xml bom2.xml --output-file output-0.16.xml

The output-0.16.xml file has no UTF-8 byte-order-mark:

merge-output-0 16-no-utf-8-bom

When uploaded to DT, it is processed as expected:

INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: dcb2d96d-2387-4f39-9c8d-33d195040d90

Repeat these steps with the latest version, and note that now a UTF-8 byte-order-mark is present:

> cyclonedx-win-x64 --version
0.19.0
> cyclonedx-win-x64 merge --input-files bom1.xml bom2.xml --output-file output-0.19.x

merge-output-0 19-with-utf-8-bom

When uploading this output-0.19.xml file to DT, it is rejected:

WARN [BomUploadProcessingTask] The BOM uploaded is not in a supported format. Supported formats include CycloneDX XML and JSON

The only difference between the accepted and rejected BOM files is the presence or absence of the UTF-8 byte-order-mark.

created time in 2 months

issue openedDependencyTrack/dependency-track

XML BOM with UTF-8 byte-order-mark is rejected as unsupported format

Current Behavior:

Upload an XML BOM file with a UTF-8 byte-order-mark (files created on Windows often have one) to Dependency Track v4.3.6. The upload is rejected with this message:

WARN [BomUploadProcessingTask] The BOM uploaded is not in a supported format. Supported formats include CycloneDX XML and JSON

If the UTF-8 byte-order-mark is removed from the same file, the upload is accepted:

INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: dcb2d96d-2387-4f39-9c8d-33d195040d90

Steps to Reproduce:

Upload this BOM file and observe the results: bom-with-utf8-byte-order-mark.zip

This was produced by cyclonedx-cli merge version 0.19.0. It appears to be a regression in cyclonedx-cli 0.19.0, as earlier versions (e.g. 0.16.0) used to not output a UTF-8 byte-order-mark.

Alternatively, open any existing CycloneDX XML file in an editor and save it as UTF-8 with byte-order-mark.

Expected Behavior:

Uploaded BOM files are consistently accepted and processed, whether they include a UTF-8 byte-order-mark or not.

Environment:

  • Dependency-Track Version: 4.3.6
  • Distribution: Executable WAR
  • BOM Format & Version: XML, 1.3
  • Database Server: N/A
  • Browser: N/A

Additional Details:

This issue happened to be detected after upgrading cyclonedx-cli and noticing automated uploads silently failing. However, files created (or edited) on Windows machines often end up including UTF-8 byte order marks; ideally, Dependency Track should handle them gracefully.

created time in 2 months

issue commentdotnet/runtime

[API Proposal]: Non-allocating Span based APIs for Hex conversion

Shouldn't bytes be a ReadOnlySpan<byte> if it is the input value? That is:

-public bool TryToHexChars(Span<byte> bytes, Span<char> chars, out int written);
+public bool TryToHexChars(ReadOnlySpan<byte> bytes, Span<char> chars, out int written);
javiercn

comment created time in 3 months

more