Initial setup road bumps #691
Replies: 1 comment
-
Hey @ChristopherHaws! Thanks so much for writing this up, it helps a lot to understand what folks with a fresh perspective are seeing.
Can you grab the error that you were encountering and open an issue for .NET 8 SDK support? It will become stable at some point, and we will need to support it at that time anyways. Currently, we don't run tests against anything after .NET 7.
This is an interesting point - I'll see if thats something we can clean up when we are scaffolding the app.
I'll look into this, I thought that the --launch-profile flag should handle it.
They are aliases of each other, but the docs should probably be consistent with |
Beta Was this translation helpful? Give feedback.
-
Hi there!
First off, thanks for creating this tool! I have been struggling to get .NET to play nicely in a JS/TS monorepo and this tool has helped quite a bit!
I wanted to document some of the hurdles I encountered when setting up my repo in case it helps others or possible gets fixed directly in nx-dotnet.
If/when I run into more hurdles, I will update this discussion with them in hopes it might help someone else! ^_^
Make sure you create a
global.json
file prior to runninginit
I struggled for a while trying to figure out why
nx g @nx-dotnet/core:init
was failing every time I ran it. It turned out it was because I have the .NET 8 Preview SDK installed on my computer, and it was being used by default since I didn't have aglobal.json
file. The fix was to run the following command prior to running theinit
command to specify the .NET SDK version to use:One possible solution to this would be to have
@nx-dotnet/core:init
detect if there is no global.json file and create one automatically for the user.nx serve my-api
was failing to startdotnet watch
When I initially tried to run the app, it wouldn't start up due to duplicate global assembly attributed being present. I see that the
bin
andobj
folders are set to use a different path than the default path, which is fine, however the templates apparently generatebin
andobj
folders anyway when first installed.The solution to this was super simple, but it took me a few minutes to realize what the cause was. To fix this, just manually delete the
bin
andobj
folders. SinceDirectory.Build.props
specifies a different location for these files, they shouldn't get generated again, so theserve
command will start working.On a side note, use a top level folder for build artifacts is going to be getting much simpler in .NET 8. See this issue for more info! :)
@nx-dotnet/core:app
vs@nx-dotnet/core:application
I am a bit confused about the naming here. Are these the same generators? In some places I see
app
being used and in others I seeapplication
being used, but I can't find any info aboutapp
in the docs.Running specific
launchSettings.json
profilesI can't figure out how to get
nx serve
to use a specific launch profile. The defaults that get created arehttp
andhttps
and the one that is being used by default ishttp
which causes the swagger endpoints to fail since there is no ssl endpoint. I tried runningnx serve my-api --launch-profile https
but this doesn't seem to fix the issue.Beta Was this translation helpful? Give feedback.
All reactions