3 ms·
You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022 https:
by doorman2 4y ago
You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/extensibility...
As you can see it's quite complicated. The contents of go.work is literally
mod1/
mod2/
Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.
- metaltyphoon 4y agoYeah the VS sln file is outdated and meant only to be used by the IDE. There are talks about revamping it, like the C# csproj had. I wasn’t aware about “not checking in go.work”. What if you want separate modules to be aware of each other but keep them in the same repo?