7 ms·

I don't know Go, but this sounds analogous to .net solution / project files - is that kind of what this is?

by taberiand 5y ago

metaltyphoon 5y ago
Yes
- asp_hornet 5y ago
  It most definitely isn’t
asp_hornet 5y ago
No. Imagine you have a nuget package your solution relies on. If you want to test a change to that nuget you would need to change the nuget reference to a local project reference or publish locally. Imagine if you could create a file on the solution level that uses the source code in a directory instead of the nuget without affecting the csproj, sln or nuget references
- GreymanTheGrey 5y ago
  Something like this would be a game changer for my workplace. This particular issue is a huge bugbear for our team of 50'ish developers in a .NET development environment, working on a large product with a lot of shared code/models/etc that often has to be updated at the same time as application logic. It is astonishing to me that MS haven't addressed this issue with NuGet workflow and its hostility towards developers working on internal code.
  - asp_hornet 5y ago
    100% agree. These pain points eventually broke me and I just left .net for Go
  - accoil 5y ago
    You can use Directory.Build.targets, and Directory.Build.props to have shared build targets/properties—including package references. When building MSBuild will keep checking parent directories until it finds those files and imports them. See: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build https://docs.microsoft.com/en-us/visualstudio/msbuild/custom... I don't use them for package references myself, but this blog post has some information on how you'd do that: https://www.mytechramblings.com/posts/centrally-manage-nuget-versions/ https://www.mytechramblings.com/posts/centrally-manage-nuget...
    - GreymanTheGrey 5y ago
      The links you've provided more deal with how to keep NuGet package versions consistent across multiple projects within a solution. While this does solve an issue, it is not the problem being discussed. Package version consistency is certainly an issue of merit and deserves attention, however for our company's use case is a minor bugbear in comparison to the issue of package references (for build) vs source or project references (for development) in large codebases that lean heavily on shared dependencies.
      - accoil 5y ago
        Ah yes! I completely the parent's point. I would actually like something like that. My current approach is to use a directory.build.props file in the folder where I clone into (i.e. outside of all the repos), and use it to set the package output path to a local folder and timestamp the package version. That way every build creates a new package to test locally, but I still have to update the references in the dependent projects when testing (and build everything separately). Not particularly happy with it, but I don't have to manage that many shared dependencies either. I wonder if a precompile target has enough access to tinker with the references? I.e. remove items from the PackageReferences item group, and create corresponding ProjectReference items. Probably will need to also call the MSBuild build task on those projects too so they can have a fresh build in case any changes have been made in them too. But yes, it would be great if Microsoft supplied something for that.
- taberiand 5y ago
  So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package? That does sound quite useful. I think this can be done relatively easily in a csproj with conditional references though?
  - asp_hornet 5y ago
    > So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package? Yes. Great for debugging too. > I think this can be done relatively easily in a csproj with conditional references though? Maybe, but you’d have to do this manually for all the projects in a solution. This is built into the tooling and produces a .gitignore-able file
rektide 5y ago
Project files are a semi complex file format specifying a lot of configuration that a given project has. One project file has no bearing on another project. Workspaces are a convention built into the language that requires no configuration. This convention applies broadly across projects equally, using identical rules for all projects. You need to download/checkout your repos in a certain way, but then they all play together.

I don't know Go, but this sounds analogous to .net solution / project files - is that kind of what this is?

metaltyphoon 5y ago

Yes

asp_hornet 5y ago
It most definitely isn’t

asp_hornet 5y ago

No. Imagine you have a nuget package your solution relies on. If you want to test a change to that nuget you would need to change the nuget reference to a local project reference or publish locally. Imagine if you could create a file on the solution level that uses the source code in a directory instead of the nuget without affecting the csproj, sln or nuget references

GreymanTheGrey 5y ago
Something like this would be a game changer for my workplace. This particular issue is a huge bugbear for our team of 50'ish developers in a .NET development environment, working on a large product with a lot of shared code/models/etc that often has to be updated at the same time as application logic. It is astonishing to me that MS haven't addressed this issue with NuGet workflow and its hostility towards developers working on internal code.
- asp_hornet 5y ago
  100% agree. These pain points eventually broke me and I just left .net for Go
- accoil 5y ago
  You can use Directory.Build.targets, and Directory.Build.props to have shared build targets/properties—including package references. When building MSBuild will keep checking parent directories until it finds those files and imports them. See: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build https://docs.microsoft.com/en-us/visualstudio/msbuild/custom... I don't use them for package references myself, but this blog post has some information on how you'd do that: https://www.mytechramblings.com/posts/centrally-manage-nuget-versions/ https://www.mytechramblings.com/posts/centrally-manage-nuget...
  - GreymanTheGrey 5y ago
    The links you've provided more deal with how to keep NuGet package versions consistent across multiple projects within a solution. While this does solve an issue, it is not the problem being discussed. Package version consistency is certainly an issue of merit and deserves attention, however for our company's use case is a minor bugbear in comparison to the issue of package references (for build) vs source or project references (for development) in large codebases that lean heavily on shared dependencies.
    - accoil 5y ago
      Ah yes! I completely the parent's point. I would actually like something like that. My current approach is to use a directory.build.props file in the folder where I clone into (i.e. outside of all the repos), and use it to set the package output path to a local folder and timestamp the package version. That way every build creates a new package to test locally, but I still have to update the references in the dependent projects when testing (and build everything separately). Not particularly happy with it, but I don't have to manage that many shared dependencies either. I wonder if a precompile target has enough access to tinker with the references? I.e. remove items from the PackageReferences item group, and create corresponding ProjectReference items. Probably will need to also call the MSBuild build task on those projects too so they can have a fresh build in case any changes have been made in them too. But yes, it would be great if Microsoft supplied something for that.
taberiand 5y ago
So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package? That does sound quite useful. I think this can be done relatively easily in a csproj with conditional references though?
- asp_hornet 5y ago
  > So a way to easily temporarily override the dependency reference to use a local project rather than a NuGet package? Yes. Great for debugging too. > I think this can be done relatively easily in a csproj with conditional references though? Maybe, but you’d have to do this manually for all the projects in a solution. This is built into the tooling and produces a .gitignore-able file

rektide 5y ago

Project files are a semi complex file format specifying a lot of configuration that a given project has. One project file has no bearing on another project. Workspaces are a convention built into the language that requires no configuration. This convention applies broadly across projects equally, using identical rules for all projects. You need to download/checkout your repos in a certain way, but then they all play together.