Does anybody know if there's a way in VS Code to tell the HTML and Markdown editors what the "root" of the site is?
I have a project where the web root lives under /site rather than / in the project, but the HTML and Markdown editors assume the root of the project == the root of the site. Short of opening just the site folder, is there a way to tell the editors where to look when doing Intellisense for links and to resolve static content in the Markdown preview?
Anybody know when we get the #Roslyn 4.10 NuGet packages (like Microsoft.CodeAnalysis)?
I'm assuming they're going to follow the "even" pattern and declare 17.10 as LTSC, which means I will want to officially support Roslyn 4.10. Both of these pages are currently out of date:
One thing that never occurred to me until retirement is how much my awareness of holidays was driven by my work schedule. Last night my sister asked me what I was doing for Memorial Day and of course I had totally forgotten it was coming up. That never happened when it was also tied to the all important bonus day off. 😂
I've been noticing whole-machine slow downs whenever I heavily use my Dev Drive (for example, building source) that are just unacceptable.
A common example is I'll start a full build in Visual Studio and then go to type in Windows Terminal and everything I type will be delayed by multiple seconds. Even pasting will show only a few characters at a time.
Oh no, it seems like the #Roslyn analyzer support in Visual Studio 2022 17.10 is broken.
Previously when you changed the target selector in the drop-down (see the screenshot), the analyzers would only show issues related to that target. Now it's showing all analyzer issues related to all targets, all the time.
This makes it almost impossible for me to interactively test how my analyzers work for a given target.
@bradwilson@dotnetbot for small instances, hashtag search is not good. Only shows posts that somehow federated to your instance which in my case is just me. But I can follow the bot directly to make sure they get here.
@matt@dotnetbot I guess you're assuming that all the hashtags would end up on dotnet.social, which isn't necessarily true either, but probably more true for your small instance. So you're still not getting everything... just more.
Reasonable use case then, I guess, but it sort of suggests that such bots should be on the biggest possible server.
I love TDD but sometimes I hate following the hashtag (purposefully not linked here) because of the posts by Scrum Shills. (Apologies if you're really into Scrum, but from my perspective it's nothing but Agile Amway.)
dotnet does not appear to require a trailing backslash when you define a custom NuGet package cache path via env var NUGET_PACKAGES but Visual Studio does.
@jaredpar I assume the answer is replacing string-concatenated paths with Path.Combine. More typing for more safety. MSBuild files tend to be all about the string concatenated paths. 😔
@bradwilson there are a lot of BYD and GWM/Haval cars on the roads here (australia) these days. of course, we don’t have a local industry to protect - but surely the u.s. would be better off subsidising its own carmakers and exposing them to some competition, rather than giving them no incentive to improve…
@banana It sort of does with the (means limited) $7500 instant rebate, assuming the car meets the rules (half for US assembly, and half for US battery components).
Found my first issue with using a Dev Drive, and wanting to have access to it from WSL: apparently the way Dev Drives mount in Windows is not compatible with the WSL auto-mounting.
Why does this matter? Docker Desktop (in WSL 2 mode) can't mount a Dev Drive folder.
Do I dump WSL 2 mode for Docker? Or do I dump Dev Drive? Tough choice, but I suspect I dump the Dev Drive.
@heaths The build times with Dev Drives is definitely faster, but not so much faster that it actually matters. The easiest path seems to be to just dump Dev Drive.
If I use a Dev Drive mounted as a drive letter, then use MKLINK /J to make a junction point from my desired local location to the Dev Drive, that's something WSL 2 does understand, and transparently translates that to a symbolic link in Linux terms. So it's really just using Disk Manager to mount it directly into the file system that's the problem.
So I can keep my Dev Drive and get Docker to volume mount things for me again! 🎉
There is something wrong with this #GitHub#UX that I can't quite understand how to fix, but the problem is this:
Almost 100% of the time when I'm writing a response in a discussion, I want it to be in response to an existing thread, not as a new post. But this UI just screams "new post please!" and relegates the "reply" functionality to visual second class.
@jaykul The complaint I consistently heard about Teams (this is several years ago now) was that their chat model basically forced everything into threads. It was very bad at just "stream of consciousness" chatting, which was how 99% of team channels in Slack worked.