Hey Richard, Hey Carl, what do you know?
Well, I know that our friend Michelle Rubusta Monte is with us to tell us about something that's going on adjacent to DEV Intersection.
What is it?
It's cybersecurity Intersection. Let's let Michelle tell that story.
Hey Michelle, Hey Carl, Hey Richard, how are you.
Tell us about cybersecurity Intersection?
Well, so, Richard and I are partnering with the group that does DEV Intersection and next Gen AI, and we are putting on a new conference dedicated to one hundred percent security focused topics. And I mean, honestly, the lineup of speakers is incredible. We have Paula A. Jenis, who's here from Poland and does keynotes all over the world and is one of the top rated RSA speakers and
black hat speaker. We're so lucky to have her. But she's not only keynoting, she's got a workshop teaches you about protecting your environments against hackers and shows you about how to you know, do attacks so that you can prevent them. It's pretty cool and sessions like that as well.
But we also have speakers from Microsoft. We have we have speakers that specialize in you know secure coding practices, Azure security, Zuero, trust architectures on Azure UH and people who do decision maker tracks, so things around governance policy and you know how to how to manage and your production operations keep them secure. So it's an amazing group of speakers, really excited about it.
And I think I can count myself among the group of speakers there.
Well, yes you can. That is great.
Yeah, I'm doing a securing Blazer Server applications talk and also I think we're doing a Security this Week live show there somewhere that is correct.
Yeah, we'll be recording Security this Week Live. We're going to have a great panel with some folks. The interesting thing here is we don't really have a Microsoft and dot net and Azure focused toecurity conference yet, so that's the reason we're putting this on as well. You know there are other security conferences, but they have a spread of topics that maybe don't focus on the things you
do day to day. And you know this overlaps with again our community of folks that specialize in again dot net, Azure and yeah, they need to keep it secure too, So with tons of talks.
Cyber Intersection is part of a trio of conferences we're doing. They have Intersection alongside the next Gen AI Conference all in Orlando the week of October fifth through tenth. That's workshops and the main conference. And you can get a special registration code if you sign up through Cybersecurity Intersection dot com.
Yeah, so if you sign up at Cybersecurity Intersection dot com, then you put in this code so Alliance cyber three hundred and you'll get three hundred off the entry price. So that's a special code that only works at cybersecurity dot com. And then you have access to all the conferences.
Like Richard said, Wow, that's cool. Thanks Michelle. I'm looking forward to it and I'll see you there. Hey, guess what. It's dot net Rocks. I'm Carl Franklin and I'm Richard Kemp and we're here for episode number nineteen hundred and sixty eight.
A good year for your listening.
Pleasure, for your listening pleasure. Yes, So David Wensche is here and we're going to talk to him in a minute. But first, how are you, mister Campbell. I haven't checked in with you in a while.
You know, post summer going into the fall conference season, I'm literally going to be traveling all of October. I'm doing like five shows and two user groups back to back. Wow, and the boss is not coming with me because you looked at it? What nah?
I was just that was my next question. Is Stacy coming with you?
No, no, she's not. We'll be together a dev intersection. Oh cool? Yeah, well you and I. Stacy's not coming for that one either, but yeah, okay Intersection and then the Azure Dev Summit and then the Norwegian show is this tron time and Stavanger.
I looked at my schedule for dev Intersection. I signed up for a lot of stuff. Yeah, yeah, and put you to work there. I'm going to be well, you sign up for something out yourself. I know, I brought it on myself.
Yeah.
You made that talk with Maddie, which is really going to be cool. You know, it's spiifying.
Rocks dot com in front of a live audience.
I think you're crazy, but I love it. It is crazy, you know me as the conference owner, delighted me as your co host.
What are you doing?
What are you doing? Especially because you've seeing my code right?
Yeah? I know.
I you usually don't fly that close to the sun. Right, you know that, guy. I've seen your demos. They're polished, their routine they work every time.
You know, they haven't all been polished. I've had some clams.
It's funny anyway, it's going to be a riot.
In the early days of Zamorin, I remember spending the first half of the workshop just getting people to Hello World because it was so difficult.
No, you should have done the workshop called get Zamoran running on your machine.
Yeah, that's basically the first half of the day. Yeah, it got easier as time went on, but back in the day, that's what we did. All right, let's run the crazy music for better no framework?
Awesome? All right, what do you got?
Well? Me, being a Blazer guy, I found this trending and true repo on GitHub from Mista Howard m I S T A h O W A r D And it's Blazer dash. Why Dash did Dash? You Dash render? Blazer Why did you render?
So it's a powerful I wonder what this does, carlus.
It's a performance monitoring and debugging tool for Blazer apps. Helps identify unnecessary rerenders and optimize component performance across server, web assembly and service side rendered environments. That's fantastic, And if you look down the features, one of the one of the best one is unnecessary render detection. Find components that re render without actual changes. Interesting and it's so
easy to do. Basically, anytime you do a state has changed in Blazer, you're forcing a rerender, but you don't always need to. And I find that this is one of the things the nuances of Blazer that most developers don't understand. When should I do state has changed, when should I not? And when should I do invoke sync state has changed, which has more to do with the
UI thread than it does a sink. But you basically, anytime you have a UI and event like a button click or something like that that's triggered from UI and you write some code, you do not have to rerender after that, it's automatically done. When you do have to rerender is when you have like a callback from JavaScript or a timer or something that isn't started on the UI thread. That's when you do that. But doing some code reviews and stuff, I see it's all over the map.
People just throw state has changed in there as an insurance policy, but it's unnecessary. So this is a great tool for that.
Awesome.
Yeah, well that's what I got. Who's talking to us today?
Richard grabbed a comment off a show fourteen seventy five, just back in September twenty seventeen, or were talked to Jesse Shadwick about the new Razor Pages in Core to Core two. A bit of a flashback. I know, I love it, Oh my god, but the comments are awesome on this show.
Wait a minute, what episode number was that.
Fourteen seventy five, five hundred shows ago?
Oh my god, that's like right before Columbus Sail the Ocean Blue. We weren't doing the what happened this year back then? Yeah?
No, please don't.
All of that history is questionable at best.
Yeah right.
This comment comes from Saint Forever, which I suspect is not their name. Also, a regular comment on the show is including today the current shows. Wow, and they go on to say another great show. I've been looking forward to the show ever since it was first listed as an upcoming show because we used to do that, used to show the upcoming roster. We don't anymore, right indeed. Asp doi net Coror Razor Pages is a well architected
programming model for developing modern WebUI. Microsoft recommended it as the best way to build both simple and complex webuyes and as the way forward for billy web locations. With all all the MVCs ceremony and please Carl and Richard at BEG you keep them coming great shows on Razor pages. Developers will adopt this program all the logue full well the Dotta ros Dowy shows on Razor Pages, and it will help them make the choice. Yeah, okay, I mean
it's been a few years, but sure, let's do one. Yeah, okay, sure, so thanks. See, Yeah, we're with you. We're a big fan of Razor Pages. That's certainly what the run as site is built out of. And although the the Dotta rock side is Blazer, of course that's my friend Carl's a big Blazer fan. Getting smallt we'll we'll keep on doing a thing. Yeah, And a copy of music Coby
is on its way to you. And if you'd like a copy of music Cobe, I write a comment on the website at dot NetRocks dot com or on the facebooks. You publish every show there, and if you comment there and I'm reading the show, we'll send you copy of music.
Go and music to codeby is what we're talking about, still going strong after all these years. Twenty two tracks, twenty five minutes long each, perfect for those Pomedoro units when you want to slip in and out of focus easily, and that's at music toocoby dot net. Then we have the collection in MP three flak and wave formats, and that brings us to nineteen sixty eight, which is the leader of the show and the things that happened in
nineteen sixty eight. Some bad things happened in nineteen sixty eight. Martin Luther King was assassinated, Bobby Kennedy was assassinated. The Tet offensive. On January thirtieth, Vietnamese forces launch a surprise attack across South Vietnam. The DNC protests in Chicago deep divisions over the deep Vietnam War and civil rights. I remember getting back to the Beatles from last week, Paul McCartney was saying, Yeah, they told us not to be political.
You know when they say, what do you think about Vietnam? Oh, bad woo, bad wolf, that's it. Yeah, two thousand and one. A Space Odyssey was released in sixty eight. Yeah, Summer Olympics. First time the public heard the phrase artificial intelligence. Yeah, ever, that's right, that's the first time. Yeah. Summer Olympics in Mexico City notable for the black Power sloop by American athletes Tommy Smith and John Carlos during the metal ceremony.
So you know, this is nothing new, this American No, this is part of the history.
Yeah.
A Civil Rights Act of nineteen sixty eight was signed into law. Great stuff, addressing housing discrimination and making a significant step in the civil rights movement. And I'll let you talk about Apollo eight.
Well, you know, an amazing because last week's show we were talking about the disaster apollowed one. Yeah, and the three astronauts lost there. And so just shy of two years later, the first humans ever leave the Earth and go beyond low Earth orbit. They Level Andmbornman and Andrews go around the Moon a free return trajectory. They get the famous photograph earth Rise by anders Yeah, and they read from Genesis.
Yeah.
But Level is also the guy who held his arm out at full length and covered the Earth with his thumb. It's like everything we've ever known YEP is behind my thumb. Yeah, it's crazy, crazy cool. It was an extraordinary moment and a real positive one, and for better or worse, it was also there was a serious picture at that moment to end the Apollo program. At that point, the Americans had finally were ahead on the space rice. They'd now done something that the Soviets had not done.
I don't think it can be exaggerated the importance of that image of Earth from space, the Earth rise, and the impact that it well, not just the earth rise, but you know, basically when we got out in the Shuttle and we're able to take these pictures that were where the Earth was bigger, but earth rise was in the pale blue dot, of course, but the picture of Earth from space is probably the biggest cultural achievement for the mythos of who are we as a race, as
the human race, and with the biggest impact since you know, the Egyptians perhaps or any of the ancient.
Astronauts to this day still talk about the overview effect that you see that the borders are invisible. Yeah, right, that the planet as a whole one. It changes the way you perceive things, really does. I got two computing ones, and we'll talk about which one is more important. The first one, I think you'll think is the most portant, but pretty sure. The second one is actually the first one is that in nineteen sixty eight the company Intel
was founded, No kidding, I Noice and more. Yeah, And their first product they'll start working hard on is making digital RAM because at that point most computers are still using Ferris core memory.
It's the idea of.
Integrated circuit memory is still novel. There's only test articles so far. They haven't really scaled it up. But the original product what Moore wrote more Law about, because this is the year that he will author the statement that will become Moore's law. He was talking about RAM. He wasn't talking about CPUs. The CPU is still two years away.
Wow.
And yet there's something bigger that happened in nineteen sixty eight. It is colloquially called today the mother of all demos. This is dougle Engelbart's demo, which was originally named a Research Center for Augmenting Human Intellect. This is the Stanford Research Institute. And he had been working on a system of computing that he called NLS, short for online system, because picking random letters out of words is something they did. Even then, he couldn't want to call it OS because
there's already operating system so online system NLS. There was about a thousand people in the audiences at Stanford, including Alan Ka, Like a lot of your foundational computing people were in the room for this demo. And this was a distributed computing demo, So not only were they at the SRI Center there, but they had these custom made twelve hundred modems and least lines to different locations. Bill
Paxton was remote. Bill English was there, and they used an edit for video projector to show the screen that Engelbert was working from on a twenty two foot wide screen. Soever you could see it. The mouse prototype, which had only been built a year or two before, is involved, and what Douglas is demonstrating is resizing windows and highlighting text. And at one point Paxton remotely edits some text that Ingelbart had written. And at the end of this ninety
minute demo, it's just this huge standing ovation. Wow, they saw the future that day. The future we were in diapers, right, this is nineteen sixty eight, we were one one year old. Yeah, the metaphors that you use in the computer today were demonstrated that day. It's why they call it the Mother of all demos.
Wow, I can't imagine what the excitement must have been like the audience.
And that's the same year as we put humans around the moon like sixty eight is horrible and astonishing.
Yeah, what are you amazing? And on that happy note, which it is actually it is introduced David So. David Wenja is a principal software engineer at Microsoft based in Melbourne, Australia. He's currently the lead developer on the Razor Tooling experience in Visual Studio and Visual Studio Code, but has otherwise been working on dot net tooling for the last seven years, with almost the entirety of that work being done in
the open on GitHub. He's passionate about good design, simple code, and delivering a constant stream of pull requests to surprise and confuse his coworker nice. When not working, he spends more time than he probably should on social media and enjoys admiring his lego collection from a respectful distance. Welcome, David, Thank you very much.
Lovely pronunciation by the way. Yeah, I'm trying you trying Melbourne right as well?
That's the Melbourne Nevin.
Yeah, usually that's the trap. Yeah, thank you for having.
Me all I remember most about Melbourne. Is it's windy all the flip and time. Sometimes a warm wind, sometimes it's a bitterly cold wind.
Yes, well, especially at the places where the conference venues tend to be, which is I'm sure what you've bunk out a lot?
Yeah? Right by the river right?
Yeh. So I have a couple of Australian terms I'd like to settle with you.
Okay.
First of all, I first, I can't remember who I was talking to when I first heard the word chuffed. That's an Australian term for really happy. I'm excited. I'm chuffed.
I'm chuffed to be here, chuff to be here.
And second one is you guys really don't put shrimp on the bobbie.
Do you know?
I don't think I've ever seen anyone do that.
And they don't say that, I mean, we don't call it shrimp. No, that's an American.
We would say prawns. Yeah, we would say prawns. And even then, but on.
The barbie, you don't do you say barbie or do you say grill? Now we say bobby, you do say barbie? Okay?
Oh yeah, we like to shorten everything.
Yeah, yeah, even McDonald's is too long. It's mackers.
Yes, absolutely, so.
I remember Adam Cogan saying let's have some brecky not breakfast hot eggs.
That's right.
And also Foster's beer is like water. You don't drink that.
Stuff, right, Yeah, we don't drink that.
No, No, I remember, Actually I was. I was in London a few months ago and walked into a to a pub there and they had it. I actually can't remember the last time I'd seen Foster's. Yeah, I have to travel internationally to do it.
So the American idea of Australia is nothing like Australia itself. You just gotta go, yeah, got to go.
The American idea of animals that will kill you. And Appeck Steakhouse no.
Yeah, yeah, I know Crocodile Dundee really and Outback Steakhouse is owned by somebody from California.
If I'm not mistaken, like you know, I would not Australian at.
All, wouldn't surprise me if they've never been to Australia. Yeah, well, then again, I've never been to an Appback steakhouse. So maybe you know, maybe I should speak at a school.
I mean, it's all right, but I wouldn't call it Australian. Yeah, all right, let's talk about the Razor experience, the Razor editor experience. I have a particular interest in this because I'm a Blazer developer mostly. And you heard our talk with Dustin Campbell, right, Yes, that's right.
Dustin's been I guess, moonlighting on Razor Tooling for a bit. He's you know, he floats around and works on what he wants to work on, but he's been helping out.
Yeah.
Yeah, he's been helping out. Heapes on Razor Tooling, doing lots of stuff on the compiler, but also lots of stuff on the two. And yes, I heard I heard your excitement at when he mentioned this new co hosting effort, and I thought, oh, well, if that's if that's interesting to people, then I can talk about that for oh, I don't know forever. I've been working on it for about eighteen months, almost exclusively.
So yeah, well, why don't you remind us what that was all about?
Sure, well, I mean let me take one step further back. So in actually almost at the time that comment that Richard red was from when Visual Studia twenty twenty two was released. I believe the first version of that. There was a new Razor Editor then and it was based on LSP, which is Language Server Protocol, which is this way to disconnect language services from the ide and have you know, sharing of code and have one server be able to go in multiple IDs, et cetera. It's really
cool idea. And the Razor Editor was the first sort of widely used LSP editor in Visual Studio. LSP had come out of Visual Studio Code and it's much much bigger part of that, just you know, by its architecture, it's more separated and things.
It's cool and so stuff being built visual Studio being brought to Visual Studio, code being brought to Visual Studio.
I didn't know about that. That's interesting.
Yeah. So actually eighty nine of the code in the Razor repository is behind sort of part of this LSP server, and the same server is shipped with vs code in the c sharp extension and with Visual Studio, and in fact there's even some bits that go the other way. So the CSS LSP server that is shipped in Visual Studio is the VS code one. They just reship it. So it's a lovely architecture and when it works, it's great.
And that's qualifier their David.
Yeah, that was very polite, kind of almost Canadian way to express your opinion about that.
Yeah, I know, LSP is great, I think. So it's not so much that the LSP doesn't work. There's dot Net projects are difficult for LSP because LSP has no concept of projects at all. And in dot net world, we're used to having cs prog files and we have references, and you know, automatically, every c sharp file that's in your folder is just picked up magically. You don't need include statements and import statements and all these wonderful things
we benefit from. Of course, the LSP server has to deal with that itself, and so what we ended up with is this situation where the Razor tooling has to understand your project, It has to understand your references so it can find your components, and that sort of thing, has to monitor all the files for changes, and we have the Roslin LSP server sitting next to it, which has to do the exact same thing for all the
sea sharp files. And at some point Raiser, the Razor compiler, became a source generator and so it plugs into Roslin, and so now Roslin has to monitor all the Razor files, and Raiser Tooling has to monitor all Raise files, and we have lots of these double handling. And Razor has a project system and Rosslin has a project system, and there was bugs in Razors and probably less bugs in Roslin's because it's a bit more battle hard and it's
got a few more users. And so a couple of years ago, while working on the Razor tooling and fixing all these lots of issues around this project system, I just sort of had the idea that, like, maybe if we just lived in the same world as Roslin, we could, you know, things would be better. We do less work, we take advantage of some of the stuff that Rosin's already done, et cetera, et cetera. And that's where this
idea of co hosting comes from. I didn't coin the name, but basically the idea is that Razor is hosted in the same world as Rosslyn, and you know that's the same process or not the same process doesn't really matter, just more they have the same view of the world context. Yeah, lsp is it's kind of like web API that that sort of change from web views to web api. It's
that sort of thing applied to IDE tooling. So in the old in the old days, maybe not the old days, but you know, in a different type of thinking, you know, you might have you might have an I frame, and let's say you go like a master detail page on a web page right right, and so you want to show an order detail inside a grid where you might have an I frame, and you say, show me the order page here, and that works, but you're getting the whole page, and so that page might need to have
some smarts to know if it's inside the grid or not or whatever. If you make a change to this doesn't apply for it's used, it's a been annoying. And so we move forward from that and we you know, have web API is now where you don't give me the order page. You just give me the data for the order and I'll work out how to display it. And that's kind of the same thinking on the tooling side.
So in a c sharp file, when you bring up the IntelliSense list, Roslin essentially is responsible for rendering that list. Under the LSP world, the IDE is responsible for rendering the list. The language server just tells it which items to put in. So it's more portable and it's flexible and all those things. Yeah, yeah, it's it's definitely. It's a cool architecture. It's just that and some of the quirks of Razor also always where it sort of shows
some of its rough edges. So Razor is, you know, five languages in one file and that's a bit difficult, right, So the Razor wrong, Yeah, that's right. The Razor LSP server in order to answer some of these questions, it would have to call to the Rosalin LSP server to get its answer, and like, hey, you know, Razer will get asked, you know, what should I show it line five of this file, and Raser has to go, well, actually line five, that's actually C sharp and that's actually
line seventy four in this generated C sharp file. So I'll go and ask Roslin what to show at line seventy four. Rosal will respond, I'll translate that back, send that back up. And that sort of stuff still happens in co hosting because it's still an LSP based editor in from the Razor point of view, but now we like that connection to Roslyn rather than making LSP calls and serialization and de serialization of data and working with
strings and sort of primitive types. That's now just a C sharp method call and we just call an API and roslins ay, give me a list please.
So I get how it's more efficient for you guys in the back end to render all this stuff, But what can you nail down the benefits to the developer this co hosting architecture, So.
I mean the benefits. The biggest benefits that you're going to see is just performance and reliability. It's a lot faster, a lot use a lot more memory, a lot less memory. Reliabilities is definitely a huge one though one of the one of the the other problem with this sort of disconnected world. Fundamentally, the Raiser language server cannot see the Roslin compilation, so it doesn't actually know about any of
the types used in your project. It doesn't know about any of the references, and so there's this communication of like component information and what is the list of components that available in this project?
For example?
We have to find that out in Roslin where there's a compilation, and then we send it across to RASA and that data has to come across. It's a lot of data and one of the key areas that Dustin actually worked on was was making that used message pack and used checksum so we could send less data if nothing's changed. And it's a much more reliable system now than it was it used to when when I first joined the team, or when Raiser sort of Raisers sort of joined the Roslin team, they came to me through
osmosis ident around here. But when that when that first happened, it was literally adjacent file serialized disc And that's why, like everyone, when there was problems with the Razor A, people would delete their OBJ folder and that would fix things. Because when they were just deleting this Jason file which was this cash and it just got corrupted or it got out of date, and so there's all the synchronization
issues trying to synchronize all this information. You know, Razor has to compile your c sharp file and it pushed it to Roslin in order for Roslam to answer questions, and that's synchronizing two systems, and we just don't need to do that anymore.
So is this why for example, if you type a type, you know you have a variable of a type and the namespace isn't qualified you In the Visual Studio code editor, you can hover over that type and it will say using blah blah blah. But in the Razor editor it doesn't do that. Like there are little things like that, like code lens is one thing that I miss in the Razorator. So you're saying that this new co hosting model will enable and facilitate those kinds of features.
Ah, that's I'm going to take that as two questions because they were both really good but very different answers unbunounced to you. So as far as the first one, yes, So you were talking about add using, and in some cases Razor does support ad using, and we do that relay thing where we ask Roslin, hey, what should we do here? But this co hosting will definitely enable us
to add more of that in future. So we in Razor we now have full access to the same compilation as rosalind, the same documents, the same project information, and so we can call any of Roslin's normal API to find out what we need to do, what we might want to do that was never possible for so all those things we can start to take advantage of now. I will say the effort so far has just been you know, we're sort of rebuilding the plane as it's going.
So we're just trying to get everything working right. The features can come from here, So yeah, that's definitely something we want to invest in. I did one sneaky feature like that I worked on a couple of weeks ago, where so go to definition in a Razer file. You could do it on a Blaser component, but you couldn't do it on an MVC tag helper. And the reason for that is because all that data that synchronizes across from Roslin, it includes type names and property names and things.
And in Blazer you can infer okay, well, if there's a component with a type name of whatever, then it's in a file called whatever, not Razer. But in MVC you cannot make that connection. Take Helpers could be called anything, they can be defined in any old class. And so we just couldn't answer this questions in Razer because all we had was a type name, but we didn't have any information about the compilation. Now, with co hosting, I
wrote some code a couple weeks ago. It just calls the standard Roslin method for hey, give me the type for this type name please, and Roslin does, and then now we know where it comes from. So we're definitely going to start to see more of those things coming hopefully.
Okay, what about the underscore imports Raiser. I always thought it was weird that we had a separate imports list for Razor components than we do for regular Sea Sharp components. Is that something that this will enable us to, I don't know, just use the CEA sharp global usings or regular using statements.
That's that's an interesting question. We definitely technically are capable of doing that. The one interesting thing about Raiser that this doesn't change is the ownership of things is a bit weird. So Razer came out of ASP dot net, including the tooling and the compiler, and probably three years ago maybe the tooling and compiler came over to Roslyn, and so the Roslin compiler team owned the Razor compiler. Rosin Ide Tooling owned Razor Tooling, which is where I
sort of came to be on it. The runtime is still owned by ASP dot net, and so those sorts of decisions are more on the runtime side. Obviously, you know, we meet with them and we have likeguage design meetings, not as often as Sea Shark, but you know they do exist, and so that's that's the sort of change we can definitely talk about.
I don't know, but there's a reason that they chose to do it that way, right, I mean.
Well that predates global usings in c sharp, So you know the reason they did that is because they were trying to solve a problem that rasor developers had and sea sharp developers, I mean, they probably had it at the time, but maybe it was less important or that just wasn't Sea sharp was ready to tackle yet. So it's sort of this you know, parallel invention thing that sometimes happened, and then you get to the end you're like, oh, we've got two systems for this, can we merge them?
And it certainly technically we can.
It's just sure is it?
How hard is it?
Will we break?
People?
Be nice to have the option like look in at you know, look at underscore imports and if it's not there, look in global usings and if it's their using yeah.
Easy, Yeah, definitely, and then all the places you'd go anyway, right.
Yeah. So the other thing you asked about though was codelin, which is interesting. So code lens is supported in visual stdio code, as you mentioned, and the code that does that is in the Razor repot. That's like we own that, that's our code, but it doesn't work in Visual studio. The reason it doesn't work.
Wea code lens works in Visual studio, but not in the Razor editor.
But not erase fun. Yes, sorry, code land's in a Razor fhile. In visual studio, code is our code, but it doesn't work in Visual studio in a Razor fhile. And the reason for that is so LSP is, you know, essentially a standard set of APIs for ID tooling. So the Razor server supports the code lens API, but the Visual Studio client doesn't.
And so that's on.
Visual Studio to you know, move further towards embracing alix per But they.
Are doing that.
Get busy they are doing.
I'll let him know.
Since version like seventeen point ten, I think of Visual do all of the error list and the squiggles and the diagnostics and everything, all of that is powered entirely through LSP in Visa studio. And that's one of those you know, rebuilding the plane things where no one really noticed we just swapped out. We were using this system.
Now we're using this system. We can get rid of the old system now and so it's slowly being adopted over there, but visual studio is twenty years of history of not doing it.
Say so, sure, it's a lot of inertia. All right, This seems like a good time to take a break, so we will be back right after these very important messages stick around. Do you have a complex dot net monolith you'd like to refactor to a micro services architecture? The Microservice Extractor for dot Net tool visualizes your app and helps progressively extract code into micro services. Learn more at aws dot Amazon dot com slash modernize.
All right, and we're back. I'm Richard Campbell. Let's call Frank. You talking a bit about to David about all the fun things in Roslin and when you mentioned co hosting Roslin and Razor together. Of course, I'm collecting links for the show, so I search for that, and I think I found the GitHub issues ninety five nineteen where this whole thing kind of kicks off, and I see you
stepping in. It's really fun for me to suddently see here's where David got involved and started doing his work all the way back at twenty twenty three.
That issue is it lives on my book Macbarr in my browser. I bet my that is my stream of consciousness issue.
It is a beast and then to the point where it has a it has a there's another issue that is a summary of all of the LSP implementations that you can see are gradually all getting checked off.
Yes, I think itels like one left.
Yeah, you're hitting a point of this is becoming a ship. Yeah, like you can see. I'll include it in the show notes for people who want to see this because it's really I love the historical sense of this, because there's halfway through this issue you guys change gears on this LSP integration mindset. You could see you clearly think bigger in it.
There was actually I think two or three points where we had to change gears and not even it wasn't even enough. It was actually Roslin. So I had the idea for this probably two years ago, and I think the first PR was January twenty twenty four, so well that's coming up to almost two years. And the basic idea was can we use the razor source generator in the ide not just at build time, and then live
within Rosalin And that was all cool. And we got together a team, you know, with Roslin, and had a bunch of meetings, which is what that stream of consciousness issue is sort of the summary of. And so all fine, we start working. And then Roslin, for you know, they obviously have their own desires and performance goals. So I think the first thing that had was they moved all source generators. Now none of them run in the visual studio process, and so if Razer wanted to access that data,
we couldn't be in the visual studio process anymore. So we now had to go over to this process, and so we rearchitected there in the middle to do that.
And then.
That you know, we sort of got past that. There's a bunch of stuff of having our own external process which we haven't had before, et cetera. And then they Rosland introduced this another thing for source generators where they now run if you set your idea up or by default, they run in what's called balance mode, which is essentially they run when you save a file and when you do a build, but they don't run on every keystroke. Because there's lots of source generators now and some of
them are a little slow. Of course, for Razor that doesn't work. We need to run on every keystroke, and so we had to adapt to that as well. And so there's been a few things where I guess it's the downside of living in the same world is where sort of we're also from the same monumental shifts that happened sometimes in that world. We were a little bit isolated before.
But sure, now your change in architecture is also added by their changes in architecture.
That's right, And I mean there's other there's changes in architecture that they could do and that are sort of on their roadmap that would make things easier for us too. So you know, it's not all I don't want to make it seem like the bad thing, but it's It's
definitely been an interesting eighteen months. And I think the biggest thing about the exciting thing for me now is like as you say, we're sort of starting to get in close to the end, is just that this is the first thing I can remember working on a Microsoft where it's a reasonable size idea and a reasonable size implementation, but it's sort of all or nothing. We can't really do this halfway. We couldn't have rolled this out piece at a time, we would have just been you know,
essentially making everything worse for everybody. And so that's a little nerve wrack, you know, the big switch it happened.
Yeah, you don't like big bangs, big bangs bad.
Yeah, well that's right. It happened about a month ago with Visual Studio code. We switched the sea Sharp extension to have this on by defaults and you know, there was a couple of little rough edges, but nothing too bad. And of course that extension releases weekly if you're on the pre release channel, so it's pretty quick to get to get a fix out. But yeah, having it on in Visual Studio is the next big the next big hurdle, So it's definitely exciting times definitely.
Yeah.
Okay, Well it's just you know, as part of the new Microsoft, the fact that the literally the thinking and how these features evolve is documented publicly.
Anybody can look at it if they want to look out.
I mean, that's one of the I would say, the reason I'm at Microsoft, but definitely one of the biggest draw cards, you know. I remember I was a sea Sharp developer in industry when Roslin was open sourced and just watching all of everything happening on GitHub and you know a few little contributions here and there. That's like with such a huge draw card for me. It's the bit about my job I love the most is that interacting with the our users on GitHub because they're all developers,
we all speak the same language. You know, we can all can we can we can shortcut a lot of things. I love that bit. And so you know, I'm I'm on read at watching when people mention it, I'm on blue Sky and masterdon and everywhere else. Just yeah, that community involvement of being on GitHub is a wonderful thing.
Does Microsoft need more contributors to the GitHub repos for all of these things? Is there a lack of Is there a perceived lack on Microsoft's part of, you know, we need more community involvement?
I think I think it's I mean, it's gift. So I don't know, I don't know the need is the right word. I think it's always welcome, it's it's a gift when it comes. I think there's some It really depends on the product, you know, sometimes, particularly say the
c sharp compiler side of Rouslom. Sometimes when they're getting to crunch time for a release, which is, you know, sort of starting about a month or two ago, their heads down fixing bugs, reviewing prs, etc. Any extra load on them to review community prs is often too much and they'll they'll have to push the community pr like to tell the person, you know, we're not going to be able to get to this for a couple of months, so, you know, and that's you know, not a great thing
to have to say, because obviously maybe someone was hoping to get something into Sea Sharp fourteen and they've missed the boat or not from their fault, you know. So I think that sort of thing can happen. But generally speaking, Roslin gets a reasonable load of community contributions that are they're all very welcome on Razer. We don't get a lot. We've had some over the years and definitely very appreciative.
I think Razor is a difficult, slightly difficult thing to get started with, just because you know, it is five languages in one and it's hard to juggle and learn about all the little quirks of Well, here's a method that sounds like it does the right thing, but before you call this, you have to be sure of these other things first. And it's not really well documented.
Obviously, I can't imagine how one would go about trying to write a Razor editor. I mean that just seems like a big, big chunk of meat to you know, to chew off.
It's it's definitely I mean I wasn't there when it started, but yeah, it's definitely an ambitious goal. In particular the way that LSP works. You know, essentially the Razor tooling
produces two files. Out of your razor file, it produces a HTML file and a c sharp file, and most you know, most of the questions that are asked about it, it actually forwards onto these other two servers and then it gets the answers back, and sometimes we have to combine them, and sometimes we have to discard some or we have to map coordinates around and it's it's interesting we get I mean, we get a lot of benefit
from that as well, though. So yeah, we don't really understand C sharp code, and we don't want to because obviously that would be writing a separate PASA, which we don't have to. That's right. One of the other big innovations that's actually on by default in dotnet ten is and fred on the ross and compiler team did this
for us. He raised a compiler now uses part of the Roslyn PASA to parse the sea sharp and so for things like interpolated strings in your sea sharp, that was something the Razor compiler didn't know how to handle, and to implement it in the Razor compiler would have been teaching it the same parsing rules as is in the sea sharp compaler. So if we can just reuse
that component, we sort of get it for free. And so there's a lot more of those, you know, like I was saying before, a lot more of those sharing things. I'm hoping that we can take advantage of. My sort of personal goal or north star maybe is right now the light bulb menu in a raiser file, we have
an allow list of which things we will show. So Roslin might suggest six things you could do to this code, but we'll only show two of them, and that's because we need to sort of vet each one and make sure that it's not going to possibly break your razor code. My north star is that we can just remove that allow list and we can just say anything that Roland
suggests we know how to handle. And so we've done it for using statements that was one of the one of the big things I remember first working on was pretty exciting. Was any anything that tries to introduce a using directive, we will now map that to a Raser using directive and they're pretty similar. So that's okay. But yeah,
we've got more work to do obviously. You know, if you want to add a method, that's pretty easy in a c sharp file, but in a Razer file you might need to add a code block, you might not you might be a code behind file.
You know.
There's all these sorts of things we need to work through.
But I'm hoping.
I'm hoping this is a new foundation we can get there from.
What do you think is the feature of the up and coming Razor editor in Visual Studio twenty twenty six that people will freak out the most about. And I'm talking about Blazer developers here. What are they going to like the most?
Well, I mean, I hope they just the thing with the Razor editor over the last couple of years is the reliability has really not been that good, and so I definitely hope that is the biggest change that they'll notice. I think the challenge is it's hard for us as humans to notice that sort of thing. We are very quick to write it off. And you know, I was mentioning about how we used to use this serialized Jason file.
I still see comments on Reddit of people saying, oh, just delete your OBJ folder and that'll fix the razor editor. Sometimes I go in there and I say, well, actually that won't do anything. We have no files in there, but you feel free to delete it. That's fine, we won't hurt.
But what a lot of times just closing the razor file and reopening it, you know, gets rid of this and recolors everything correctly.
And yeah, that's right, and so that that I'm hoping that we have to do that less. In fact, I'm hoping you have to do that never, especially the colors one. That one we have a we actually have a name for that internally. We call that Disco colors. And it's pretty well, pretty well known issue. Yeah that with co hosting. With co hosting, that should be completely a thing of the past. The question is whether anyone will will notice, because you know, when things are working.
Of course there will, we'll see. The other thing is, dude, I have an I nine computer with sixty four gigs of RAM, and it's still happens on my computer.
Yeah, I mean that one, that one's not a performancing, that one's just keeping these two worlds up to date. That one's that What that means is, you know, Rosen thinks that there's a there's a class from you know, character four to character seven, and Razer thinks that's a character seeks to character whatever, and we just get the colors from it. But so that one should be thin. But yeah, and the other thing is performance, and the big the big win for performance with co hosting really
is hot reload. So with the old editor, we you know, the Razor tooling compiled all your Raiser files and Roslin compiled your Razor files. At build time and obviously at runtime, both of those two things can be in play, and so hot reload has this code to map from. We essentially have two solutions in memory, ones called design time, which is what you're looking at. One is called runtime, and hot reload has to map between the two, et cetera. And all of that just goes away now because co
hosting uses the same source generator, build time users. And so I mean, I can't remember off the top of my head, but Chris on the Razor Compiler team produced a series of graphs of that some of the time savings for large projects were just astronomical, and it's just we're just not doing a whole lot of work we had to do before, and so hopefully that impacts.
We have a ten second rule for het reload. If it does an update in ten seconds, I closed, I stopped the app and run it again. It's just one of those things.
Yeah, so yeah, that that should be a big win as well.
Yeah that's great. But yeah, well these dall sound really fantastic and yeah, very powerful and as I mentioned before, paving the way to parody with the visual Studio code editor that we desperately want. So this is all good news. Is there anything else that we didn't touch on that you want to talk about?
I don't think so, you know, as I I could talk about this stuff.
For a while. You know, we're not pressed for time. We have someone if you want to continue.
I mean, the main part about what do you think in the terms of testing for all of this, because I think it's always a challenge with these mixed language files. It's like, how do I know that it's working correct?
Yeah, So that's that's Actually, that's one really big influence that I think. So, as I said, right started an asp on net. When it came over to Rosalin, two of the people from the asp on net team came over with it, and so they were heading up the Razor effort, but they were under Roslin, and over time, through Riors and people getting promoted and some leaving Microsoft,
et cetera, that it's all changed out. But the I feel like what we've been working on, you know, me and Dust and the rest of the team over the last few years is sort of the rosalindification of Razor taking all these things from and so the testing is.
Meme has stuck around. Right to me, it'd always felt temporary that this was the new version of c sharp, this sort of compiler of a service mindset, but it just yeah, it turns it seems like everything compiler related has lived under Roslin ever since.
Yeah, sometimes codenames stick, you know, But yeah, the testing front, the testing front is definitely something we've we've taken from them, and so there's a bunch of new tests for hosting in the Raisor repo, and every single one of them is written as what I would call a Roslin style test, which is really like snapshot testing, where we essentially have here's your raser document, here's your operation you want to run,
and here's what the raser document should look like. The older styal tests that come from more on the ASPN and outside, they're more written like a library test, written because asp dot net developers were all used to writing libraries right like, it makes total sense how they got there. It's just an interesting difference. And so there's lots of mocks, and there's lots of unit tests of specific this method should do this. And in the tooling side, we don't
really care what that method should do. We just care that the user's code looks how they think it should look after they've done whatever of they've done. And so I think that's a big part of it. I think one of the interesting things when we go to graduate co hosting from being a an experiment and let's put it out there and see if it breaks, to actually, okay, it's great, let's turn it on and we remove some
of the old code. The temptation is, oh, we don't need this test assembly anymore because none of this code is real. But I think we actually need to go through that test code with a little bit of a fine tooth comb, because there's probably some little nuggets in there that we maybe don't have coverage on that, you know, we need to add in the newer style.
Good stuff. What's next for you, David? What's in your inbox? Your to do list?
Well, not a lot because the wonders of time zone differences mean I get most of the day to myself. So no, the thing I'm working on, I'm still just you know, trying to basically land this ship, you know, work out how to pull out some of the older stuff and make it as efficient as possible. Very very keen to see the feedback from people, and I'm I'm hesitant to take on too much right now because I'm just poised for the bugs. But if you see them, if you see them, log them and of fixham.
That's great.
Take the preview out for us bin try this on.
Yeah, absolutely absolutely, I'm looking forward to it. Yeah, okay, Well, thanks very much for spending the hour with us.
David.
It's great pleasure to talk to you, and we're going to have to have you on again. If you have anything that haply comes up that you want to talk about, feel free to reach out. Thank you all right, and we'll talk to you next time on dot netwoks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t R O c K S DOM for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code, see you next time.
You got jud Middle Vans
And the