Comments (5)
Yeah, there would definitely be more duplication in the nx-dotnet.config.js. I am still personally leaning more towards utilizing it as xml manipulation is bit more painful that just updating the js exports.
Keeping built application sizes down by dotnet not knowing about the js config file is definitely a benefit.
Either route we choose a sync-packages schematic will be needed in case changes are made inside visual studio. A more generic vs-sync schematic might be nice in case there are further things that crop up as not being cross-compatible.
There are pro's and con's to both. Here is how I see it.
nx-dotnet.config.js
Pros:
- Small file, easy to read at a glance
- Easier to manipulate from a schematic
- .NET CLI handles all XML manipulation
Cons:
- Does not actually affect the build
- Visual Studio + dotnet do not know about this file.
Directory.Build.props
Pros:
- Packages listed here do not have to be included into project files.
- Visual studio is somewhat aware of this file.
- Validation of sync state is easier, do not care about the versions.
Cons:
- Updates made inside of VS apply to the project files, so this still has to be updated.
- XML is harder to update
- Packages listed here are added to the built projects, regardless of if they are used.
I am mostly leaning towards the config file, mostly due to the last con on the directory build props file. There are definitely benefits to the directory file though. The nx-dotnet schematics will have to read xml either way, but we already include xmldoc for reading these to parse dependency tree.
from nx-dotnet.
This could be accomplished with a shared MSBuild properties file named Directory.Build.props. This file will automatically be imported into each project found below it in the file system. It may contain any MSBuild property, including <PackageReference />
elements. If the Directory.Build.props
file is created next to the workspace's package.json
, it will automatically apply to all current and future .NET projects. If all NuGet packages are saved there (rather than the individual project files), then it effectively functions like package.json
, providing single-versioning for the workspace. The biggest drawback is that the dotnet CLI doesn't support this pattern. Any packages added through the CLI are added to the individual csproj files; updating NuGet packages would require hand-rolled XML manipulation.
from nx-dotnet.
Hmmmm, thats an interesting idea. I did not know about the directory file like that.
Like you said the dotnet cli would not install new packages to that by default though, and if anyone was to open a project in VS the package manager would not know about these packages.
Perhaps it would be better to have a section in the nx-dotnet.config.js file that has package versions listed in it, and update that section when someone uses the cli to install a package.
We would provide 2 schematics to facilitate this. One that adds the package reference to the needed csproj file, using the version from the config file if it matches or prompting a decision if it does not match. The other would be called something like sync-packages and would scan project files in the workspace and update the config file. This 2nd schematic could called at the end of the first, but would also allow it to be ran in case a dev had messed with packages from the manager
from nx-dotnet.
Visual Studio 2019 recognizes packages that live in Directory.Build.props
when using the visual package manager, but any changes made within that package manager are saved into the csproj
file, including updates made to packages that already live in the global file.
No matter which global file ends up holding the shared packages, a schematic to rebuild the global file from the individual projects would be a nice addition. It would be useful when the projects are modified directly and when existing .NET projects are migrated into an Nx workspace. This schematic could also be used as a CI linter that ensures all packages live in the global file and there's no inconsistencies.
Between the choice of Directory.Build.props
and nx-dotnet.config.js
, the props file leads to less duplication. With the JS file, all packages are listed there for the benefit of the schematics, but all packages must also be listed in the csproj
files for the benefit of the compiler. With the props file, all packages listed there are visible to both the schematics and the compiler (though the schematics will need XML parsing, which isn't as clean as JSON). Then, validation that the projects are in-sync is simply a check that they don't contain any package references (no need to compare version numbers).
On the other hand, using an "invisible" config file allows the schematics to only include the packages that are actually used by the individual project. The dotnet CLI will include all referenced assemblies, including those that are never used, when building or publishing an application. Setting up each csproj
with only the packages it actually uses matches the pattern of publishable libraries that Nx uses with npm packages.
from nx-dotnet.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
from nx-dotnet.
Related Issues (20)
- [BUG] Dependencies not automatically resolved during build HOT 7
- [Feature] Build A solution file instead of csproj. HOT 2
- npx nx g @nx-dotnet/core:application -d services/apps/DevApiGateway does not put the project in the correct directory
- project.json not generated HOT 9
- [BUG] changes in test command execution HOT 4
- Support `--no-build` option in serve target HOT 1
- [BUG] MSBuild properties not supported for build and nx graph HOT 1
- [BUG] nx-dotnet / msbuild explodes links to dist/intermediates within project folder HOT 1
- [BUG] solutionFile specified in nx.json not used when creating new app HOT 1
- [BUG] Generating webapi does not seem to work in new nx workspace HOT 6
- [BUG] check-module-boundaries.js adds significant time to test workflows
- [BUG / REQUEST] When running npm install, dotnet restore is automatically fired - option to skip this HOT 1
- [Feature] ability to run "dotnet watch build" HOT 2
- [BUG] *.WapProj not found HOT 4
- [BUG] - warning for each dotnet project: Project '{name}' contains extension with invalid name (type) HOT 2
- [BUG] targetDefaults in nx.json doesn't work
- dotnet format is in dotnet sdk since dotnet 6 HOT 3
- [BUG] Renaming .csproj results in build errors in dependent projects due to cache
- Need ability to disable hot reload when using @nx-dotnet/core:serve and/or @nx-dotnet/core:test
- [BUG] check-module-boundaries.js sometimes fails: EPERM: operation not permitted, rename 'project-graph.json~ab440dc1' -> 'project-graph.json' HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nx-dotnet.