Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with Project References during sln analysis #826

Closed
sanekj opened this issue Jan 9, 2024 · 2 comments
Closed

Issue with Project References during sln analysis #826

sanekj opened this issue Jan 9, 2024 · 2 comments
Labels
triage Don't know what to do with this yet

Comments

@sanekj
Copy link

sanekj commented Jan 9, 2024

Release: 3.0.4
I have an issue after upgrade to version 3.0.x because there are always enabled project references (if I analyzing any sln file).

I'm using project references in dev mode (see in picture).
image
This reference is not used on build server because there is used reference from published version in nuget.

Command:
dotnet CycloneDX MyProject.sln --out D:\SCM_REPOS_temp\sn\ --json --exclude-test-projects --exclude-dev --disable-github-licenses --disable-package-restore

Exception:

Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\sn\lib\Lib\CommonLib.csproj'.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at System.IO.Abstractions.FileStreamFactory.New(String path, FileMode mode)
   at CycloneDX.Services.ProjectFileService.GetProjectNameAndVersion(String projectFilePath) in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Services/ProjectFileService.cs:line 86
   at CycloneDX.Services.ProjectFileService.RecursivelyGetProjectReferencesAsync(String projectFilePath) in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Services/ProjectFileService.cs:line 312
   at CycloneDX.Services.SolutionFileService.GetSolutionProjectReferencesAsync(String solutionFilePath) in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Services/SolutionFileService.cs:line 73
   at CycloneDX.Services.SolutionFileService.GetSolutionDotnetDependencys(String solutionFilePath, String baseIntermediateOutputPath, Boolean excludeTestProjects, String framework, String runtime) in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Services/SolutionFileService.cs:line 99
   at CycloneDX.Runner.HandleCommandAsync(RunOptions options) in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Runner.cs:line 167
   at CycloneDX.Program.<>c__DisplayClass0_0.<<Main>b__2>d.MoveNext() in /home/runner/work/cyclonedx-dotnet/cyclonedx-dotnet/CycloneDX/Program.cs:line 137
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.AnonymousCommandHandler.SyncUsingAsync(InvocationContext context)
   at System.CommandLine.Invocation.AnonymousCommandHandler.Invoke(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__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()
@github-actions github-actions bot added the triage Don't know what to do with this yet label Jan 9, 2024
mtsfoni added a commit that referenced this issue Jan 9, 2024
@mtsfoni
Copy link
Contributor

mtsfoni commented Jan 9, 2024

I make a fix for this in 3.0.5. However, CycloneDX doesn't know how to handle such conditional Project References it should run without crashing, but the results may be (and have been) flawed because of this.

Probably there is a good reason why your pipeline has access to a feed that the developers have not.

3.0.5 should hit tomorrow evening European time.

@mtsfoni
Copy link
Contributor

mtsfoni commented Jan 10, 2024

Please try with: 3.0.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Don't know what to do with this yet
Projects
None yet
Development

No branches or pull requests

2 participants