Event banner
Event details
76 Comments
- Any chance that we could a functionality similar to VS Code and WSL, where we use a folder hosted inside WSL to work on our projects? I know that today we can debug an app saved on a windows folder on WSL, and that is not I'm saying here. Hope I was clear on what I meant.
- Andy Sterland
Microsoft
Sounds like you'd like the VS Code developer containers feature in VS? We don't have plans for that just yet. But there is a Developer Community suggestion at https://developercommunity.visualstudio.com/t/Add-devcontainers-to-VisualStudio/625664?space=8&q=devcontainers that you should vote and comment on!- No, what I want is the ability to open solutions from inside the WSL folders, and build and debug them from there. If you clone a repo on a WSL instance, and then do a code ./repo-folder, you open vs code on windows, but the vs code server process is running inside WSL.
- Has the Visual Studio team benchmarked against JetBrains Rider? Some of my co-workers use it and I'm being constantly reminded how well it performs.
- timheuerWith the move to 64-bit as you can imagine performance is is topmost in our mind. We are looking at the key developer experience interactions and ensuring that we are optimizing performance for the key use cases for developers. But yeah, tl;dr - we are looking a LOT at performance and responsiveness (UI responsiveness as well) for VS2022 What we'd love to hear is the specific scenarios you are seeing that we should make sure we're optimizing -- load times, editor responsiveness, etc? That would be helpful to prioritize!
- The two big ones I've seen are startup (including solution load) and global search. I know solution load is an area that's improved, so I'm eager to try the preview in a week or so when my workload lightens. As for search, I think Rider creates a persistent index of all files, so searching is nearly instantaneous regardless of solution size, and may contribute to its fast startup, too, since it would only have to check for changes to the indexed files. Obviously I won't have more detail until I try it, which will be after this AMA window--I assume the built in report feedback UI is the way to go, then?
- Why the general recommendation to split an extension, rather than make it work with both old and new runtime? (worked well for me)
- Andy SterlandWe've updated our guidance https://docs.microsoft.com/en-us/visualstudio/extensibility/migration/update-visual-studio-extension?view=vs-2022 to be a little clearer that you should do what works for you and that splitting is not always the right path. Initially we were more strongly leaning on the advice as splitting because it was the 'safer' option. It would ensure your current code against VS2019 would work while you make any changes to target the evolving VS2022.
- Is there any roadmap for Visual Studio Modeling SDK in VS 2022? Or is it discontinued? Also there aren't enough doc for this SDK, as far as I know...
- mkristensenIt's supporting 64-bit in VS 2022, but it won't see other updates for now. What are you using it for today?
- Any plans to update https://www.nuget.org/packages/Microsoft.VisualStudio.ProjectSystem.Sdk/ from preview?
- mkristensenHej Erik :) No, there are no plans to update the existing ProjectSystem SDK under the current extensibility model. I expect a brand-new API for solutions and projects under the new extensibility model at some point in the future.
- Fine, will stick to that, seems the only way to enumerate packagereferences in a SDK style project
- Wonder if the SourceGenerator engine could be moved out process and have it either self-contained (aka net6) or choose like a `TargetSourceGenFramework> net6`
So far the set of api is restricted to ns2.0 due to that runner being limited
the price to pay is a bit more than we could expect- timheuerIs there a specific API you are longing for in your Source Generator usage? Given where/how source generators execute the .NET standard 'base' is a choice we made right now. I think ideally here having VS being able to host/run .NET6 apps is what will ultimately help here and enable the scenario you are talking about. But tell me more and maybe we can identify a clever current way.
- let's imagine i'm parsing file like CSV or XML to generate typed model using span and all associated goodness to have new zero allocation while parsing the file i understand there's other way but that's just an example there probably douze other idea using api for netcore/net5+ i'm just asking to let the user choose his own "SG SDK" so a sort of it own "isolated build" outside of IDE constraints
- Would it be possible to have full "tye" support in vs2022 ? idea is just to press "F5" and have a "profile" for tye. sort of like "bridge to kubernetes" that would finally allow to have the "startup project" or multiple startup project not destroyed every time the repo is cleaned (aka the .vs/ folder) having a `debug: true` in that yaml for example would be a blessing
- timheuerWe're looking at tooling around this and how to bridge a few concepts here. One key scenario you note here that we're keen on looking into is better multiple startup project support. Is that your key scenario/win when you use the Tye tooling? We recognize that people are working more and more with multiple microservices/clients that all need to talk to each other locally and a better F5 experience is desired here. We've outgrown some existing ones. It isn't a committed feature yet, but we're discussing/designing.
- it's not just micro service to be fair it's useful in demo env / end to end / local dev let's say you have a monolith with 3 backend (other team / can't control) designing 3 dumb webapi with the same set of endpoint allow to work in isolation or have specific behavior it helps designing new code if the backend did not released it for example that also helps having isolated end to end with predictable result and not subject to backend down time / instability / authn credential
- Great work on VS 2022, especially on the keeping the surprise part. It is quite stable and snappy on a 250 project solution. What kind of feedback are you looking for at this very early stage in the game? For example, the only crash I saw so far on a large solution was in C# extracting class to new file - seems that this or any external change to a csproj adding a file will cause this - however it seems like it would already be known due to such a simple trigger and so I shouldn't bother reporting it.
- timheuerWoohoo! Glad to hear that your 250 project solution is snappier! We're looking for any/all feedback, of course ensuring that your existing experiences and performance expectations are met, that would be key feedback. Don't assume anything is known and in fact using the VS Feedback tool helps us get diagnostic information about your specific environment that may be helpful in situations triaging an issue. So on the extracting class, please indeed report it using the Feedback tool when you hit it (those are the best times closest to the repro) and feel free to ping me directly with the link to the issue you logged. But keep the feedback coming...DON'T HOLD BACK!
- If I report after a crash it has the minidump included from the last crash, then? That is pretty awesome!
- After you decided to kill C++/CX in name of C++/WinRT, the Windows developer community lost the only tool on the Microsoft stack that offered any kind of RAD tooling for C++ GUI development comparable to C++ Builder and Qt/QML from the competition. These products not only offer a .NET like development experience to C++ developers on the Windows platform, they also allow us to create cross platform applications with such tooling. The teams responsible for the introduction of C++/WinRT and respective deprecation of C++/CX keep ignoring the tickets on Developer Community and Github, that we want a proper developer experience when writing IDL files (hardly changed since MDIL 1.0 was introduced), not having to manually copy and merge generated files, or manually connect XAML with IDL written components. Will Visual Studio 2022 finally bring a C++ Builder / QtCreator developer experience to C++ developers on Visual Studio, catching up with 25 years of delay, or this is a lost battle and we should just move on to the platforms that actually care about our productivity?
marianluparuHello, thanks for sharing your thoughts. I can assure you that Visual Studio 2022 will continue to support C++/CX too. Work on improving the C++/WinRT experience is still ongoing and I hear you that the experience is not yet there when compared with C++/CX. Since at this time, work on Reunion and WinUI are progressing primarily with C++/WinRT support, one important piece of news I can share is that C++/WinRT support will be available in the VS 2019 version 16.11, as well as VS 2022 (directly through the VS installer). This is the vanilla experience that you are familiar with, but we hope that this will lead to more widespread adoption and more feedback from the community on C++/WinRT's dependency on MIDL- Thanks for the update. It would already be a gold improvement if IDL files had support for syntax highlighting and completion, I would expect that when you decided to replace C++/CX with C++/WinRT care would be taken for such simple stuff before deciding C++/CX was going out. Right now I am advocating customers to keep using MFC or migrate to C++ Builder/Qt if within their project budgets.
- Hi all. What timeframe will we begin to see the new APIs/features for the new extension model?
- mkristensen
When Visual Studio 2022 comes out of preview, the first piece should be ready. It's an API for handling language servers through the Language Server Protocol. Over the following years, we expect the API to grow such that it can eventually replace the existing VSSDK. This will take several years, and we don't recommend waiting to implement any features in anticipation of the new model.
You may find the new community driven toolkit and VSIX Cookbook interesting in the meantime. You'll see that effort align more with the new extensibility model over time, so any transition can be done more smoothly.
