4 ms·
This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to
by metaltyphoon 4y ago
This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to you (aka git clone, git submodule)
- doorman2 4y agoYou 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?