Skip to content

Conversation

@KevinRansom
Copy link
Contributor

@KevinRansom KevinRansom commented Oct 14, 2022

It appears that we have been building vsix' twice.

So in order to ensure we are not so wasteful, and to ensure that the arcade team are not struggling with our wasteful build. I have made it a tad more efficient.

O.K - so the above is rubbish:

  • the real issue is that the build of Microsoft.FSharp.Compiler.sln is essential, and it needs separating from visualfsharp.sln somewhat, because of how and what we insert into the SDK.

The issue is that when arcade is building sbom's for the insertion phase (sbom means secure bill of materials) it generates them for each solution build, it performs. Unfortunately it will have already done this for VisualFSharp.sln, and so when it repeats this for Microsoft.FSharp.Compiler.sln this fails because it has already added the sbom's created by the previous solution. The way the sbom tool works is to add a list of files generated by scanning the intermediate output directory for vsix'.

The fix presented here disables sbom generation when building Microsoft.FSharp.Compiler.sln. This is okay because Microsoft.FSharp.Compiler.sln will never generate a vsix for insertion into VS.

@KevinRansom KevinRansom changed the title fix build Do not merge: fix build Oct 15, 2022
@KevinRansom
Copy link
Contributor Author

Whilst this does fix what @epananth was struggling with it's still not the right fix.

The Microsoft.FSharp.Compiler.sln build is necessary to build the nuget package for insertion into the SDK.

I think we probably need to turn of sbom generation for this solution because it generates no vsix.

@KevinRansom KevinRansom changed the title Do not merge: fix build Fix build for sbom generation. Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants