docs: better bootstrapping xp #11124
Conversation
|
@davidwengier , started to get a hang on this repo and found some smaller areas to improve the docs. |
|
@dotnet-policy-service agree |
| @@ -63,6 +69,12 @@ Before opening the `Razor.sln` file in Visual Studio or VS Code, you need to per | |||
| of Razor to be deployed. This can be useful if the latest Razor bits depend on a breaking change in | |||
| Roslyn that isn't available in the version of Visual Studio being targeted. If you encounter errors | |||
| when debugging the Razor bits that you've built and deployed, setting this switch _might_ fix them. | |||
| > :bulb: Windows tip: if you encounter errors pointing to `path-too-long` errors, like `The fully qualified file name must be less than 260 characters.`, consider shortening your local path with `subst`, where `R` is a free drive-letter, e.g. | |||
There was a problem hiding this comment.
I wonder if instead we should add a reg file like roslyn has https://github.com/dotnet/roslyn/blob/main/eng/enable-long-paths.reg
There was a problem hiding this comment.
yeah, this variant just got me starting to be actually be able to work with this repo.
Might as well not "fix" the issue, if pathes got any longer - but did the trick in the meantime (as only two files exceded the path-length for me).
Relying on a registry setting might put some additional burden on potential contributors, even if this "seems" to be safely applicable on modern-ish versions of the OS, though. But then, having someone need to apply an (unknown) registry-key import might not benefit overall acceptancy when starting to contribute...so maybe we could just leave a hint to the link you provided? Maybe the roslyn-project has some notes on that in their docs, which we could refer to...
There was a problem hiding this comment.
It seems logical to me that if we tell people to enable long paths in git, we should tell them to do it for Windows too. Roslyn also has this to detect and warn on build, which we should crib:
https://github.com/dotnet/roslyn/blob/9e862f15fc4d57a479ac45724748a41c87a7d0b6/eng/targets/Imports.targets#L164-L170
BUT I don't see any reason that any of that should hold up a docs update
There was a problem hiding this comment.
As far as I understand, roslyn "needs" long-paths to be enabled at build time:
https://github.com/dotnet/roslyn/blob/697989601cb5319af38ca7c36d8727875c4f49c4/eng/targets/Imports.targets#L164C2-L170C13
I´ve got the feeling that this warning might get easily overlooked...but seems more straight forward / error-proof than relying on s.th. like subst.
I'll revisit this part, stay tuned...
There was a problem hiding this comment.
Roslyn recommends it and checks in their builds https://github.com/dotnet/roslyn/blob/9e862f15fc4d57a479ac45724748a41c87a7d0b6/eng/targets/Imports.targets#L169
@jaredpar have you heard of any potential burden for contributors?
I'm fine with recommending both as an option since it's to unblock people in a way that they're comfortable with. Alternative to a reg file we could add the powershell equivalent
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value "1" -PropertyType DWORD -Force There was a problem hiding this comment.
The "burden" is just anticipated, as I personally faced it while trying to contribute ;)
I`ll think about how this could be integrated in a way, which would ease up the first-time experience when working with the repo, cool?
Applying suggestion from code-review Co-authored-by: Andrew Hall <ryzngard@live.com>
|
@earloc no idea why CI is failing, but you can leave it with us to this merged |
Summary of the changes
Fixes:
Some initial confusion when starting to work with the repo