Dependency Graph not finding dependencies on class libraries when using MacOS #43
Comments
photomoose
added
bug
AgentEnder
removed
the
needs-triage
|
Hey @photomoose! Thanks for this issue, excited to see people trying this out on non-windows machines as I am sure that is where the plugin should shine. I think I know what causes this, will get a fix out soon. |
MacOS / Linux use different directory separators, and we relied on it being a forward slash. fixes #43
## [0.5.2](v0.5.1...v0.5.2) (2021-05-18) ### Bug Fixes * **core:** dep-graph with various directory separators ([3beccb4](3beccb4)), closes [#43](#43)
|
🎉 This issue has been resolved in version 0.5.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
@photomoose Let me know if you are still having issues with this, I don't have a mac available for testing just yet. |
|
@AgentEnder thanks for the quick fix, but unfortunately this didn't actually resolve the issue! I will take a look at it to see what's going on... |
|
Ah, drat. I'll see if I cannot get to the bottom of this later tonight. |
|
I was able to reproduce this via WSL2, so I should be able to publish a fix more confidently. |
inconsistent directory separators between .net CLI caused path.resolve to behave weirdly. fixes #43
## [0.6.2](v0.6.1...v0.6.2) (2021-05-19) ### Bug Fixes * **utils:** getDependantProjectsForNxProject should work on Unix ([96cbc33](96cbc33)), closes [#43](#43)
|
🎉 This issue has been resolved in version 0.6.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
@AgentEnder I can confirm this now works! Cheers. |
|
Haha! Excellent. Thanks for the confirmation. Anything else bumpy on non-windows machines? I really want to keep mac / linux first class. |
|
Not yet, I haven't really used it in anger yet, I'm still trying to get a feel how this might work with a .NET project / mono-repo... Our .NET applications run inside K8s, so our build artifacts are Docker images, where the Dockerfile copies the .NET source code into the build container and compiles it into a final image - (which can be achieved by bringing in the nx-docker plugin and adding a docker target to workspace.json) - your dependency fix now ensures the Docker images are built when changes occur. Building / running tests locally is typically done inside the IDE (i.e. Rider) so we don't really need to invoke nx as part of our local dev workflow. However, on the CI server, we run the tests inside Docker containers, running as part of a Docker Compose network with other dependencies (e.g. Elasticsearch etc. for integration tests) - this allows us to have no dependencies on the build agents, everything is inside containers. I'm trying to think how we might be able to do something with nx here... I'm also trying to workout whether we should have a single build/deployment pipeline for the mono-repo as a whole or individual pipelines for each service in the mono-repo... |
|
Understood. I do not have a ton of experience with docker + kubernetes (really painful on windows), so it has not been something I have heavily considered with the plugin. Local development inside of an IDE like rider or Visual Studio is also something that is not a core focus for the plugin, but is something that we will strive to maintain. If a project is opened up in an IDE, nothing the user does there should break the nx plugin, and everything done there should be accounted for by the plugin in some way (e.g. the sync generator pulls in dependencies added by an ide instead of through the plugin generators). The build/test/serve executors really shine when using vs-code or any other editor that does not have first class support for .NET. These also really shine in CI for cases w/o kubernetes, as the The end goal of this plugin is to enable cross-language repositories where you can house your typescript front ends + .NET back ends in the same repo, and use the same commands to build and test them. Another part of this is the hopeful integration of typescript class generation from the .NET OpenAPI / swagger docs (#4 ) |
|
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. |
Describe the bug
When using MacOS, the nx dependency graph does not show dependencies on class libraries from apps.
To Reproduce
Steps to reproduce the behavior:
nx generate @nx-dotnet/core:app Demo.App)nx generate @nx-dotnet/core:lib Demo.Lib)nx dep-graph)Expected behavior
The dependency graph should show a dependency on Demo.Lib from Demo.App.
Environment:
Additional context
After some investigation, this problem appears to be caused by the fact that the DotNet CLI writes project reference paths into the *.csproj files using backslashes, for example:
If you manually edit the *.csproj file and convert the backslashes to forward slashes, then the dependency graph works as expected:
Strangely, if you create a unit test project for the app when prompted by nx, then the dependency from the test project to the app works fine despite the use of backslashes - maybe this works because it doesn't have to go up a folder to the libs folder?:
It looks like the DotNet CLI creates project references with backslashes; I wonder whether there's an issue with how
resolveis calculating the paths here: https://github.com/nx-dotnet/nx-dotnet/blob/master/packages/utils/src/lib/utility-functions/workspace.ts#L60The text was updated successfully, but these errors were encountered: