Proof of concept using different base paths #2079
Conversation
| | Error msg -> Promise.reject (exn msg)) | ||
|
|
||
| let invokeMSBuildWithCancel project target (cancellationToken: CancellationToken) = | ||
| let invokeMSBuildWithCancel project target (cancellationToken: CancellationToken) args = |
There was a problem hiding this comment.
We're doing the classic calling msbuild t:Build here instead of dotnet build which can cause issues with needing to restore. This is currently in a hacky state so we can discuss options.
There was a problem hiding this comment.
on thing to consider is that /t:Build calls the build target - and not all projects will have that target. Most managed projects will, but what dotnet build and msbuild do by default is call the default target so the most correct thing to do might be to allow specifying an optional target?
you can also do dotnet build with --no-restore if you want to skip the implicit restore.
| module Project = | ||
| let testPathSubDir = ".ionide-test" | ||
| let getOutputPaths () = | ||
| let objOutputPath = node.path.join [| "obj" ; testPathSubDir ; node.path.sep|] |
There was a problem hiding this comment.
Using relative paths means it can build each respective project in its own subfolder (Real lib and test project), otherwise, things like project.assets.json will collide. . Though I'm not entirely sure this is the correct approach.
There was a problem hiding this comment.
using separate subfolders is the right move here IMO
There was a problem hiding this comment.
This is the same discussion that's going on for the dotnet run foo.cs work, and separate intermediate/output paths is what that effort has landed on as well.
|
cc @farlee2121 |
| type TargetFramework = string | ||
|
|
||
| module Project = | ||
| let testPathSubDir = ".ionide-test" |
There was a problem hiding this comment.
idea: consider using ExtensionContext.storageUri from the activate call to provide our workspace-unique state path?
Closes #2078