September 17, 2025 • 53 mins
Razor Tooling is evolving! Carl and Richard talk to David Wengier about the changes coming for Razor Pages in the next version of Visual Studio. David talks about the realization that much of the new work in Razor ties closely to Roslyn, which has resulted in a new co-hosting model that means higher performance and reliability for your web pages! The conversation delves into how capabilities in Visual Studio Code are shared with Visual Studio and vice versa, as well as the role of the Language Service Protocol in making it easier to bring more powerful tools to you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Hey Richard, Hey Carl, what do you know?
Speaker 2 (00:03):
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.
Speaker 1 (00:11):
What is it?
Speaker 3 (00:12):
It's cybersecurity Intersection. Let's let Michelle tell that story.
Speaker 4 (00:16):
Hey Michelle, Hey Carl, Hey Richard, how are you.
Speaker 2 (00:21):
Tell us about cybersecurity Intersection?
Speaker 4 (00:23):
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
(00:43):
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
(01:03):
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
(01:26):
production operations keep them secure. So it's an amazing group
of speakers, really excited about it.
Speaker 2 (01:31):
And I think I can count myself among the group
of speakers there.
Speaker 4 (01:35):
Well, yes you can. That is great.
Speaker 2 (01:37):
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.
Speaker 4 (01:48):
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
(02:10):
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.
Speaker 3 (02:23):
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.
Speaker 4 (02:42):
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.
Speaker 2 (03:04):
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
(03:27):
Kemp and we're here for episode number nineteen hundred and
sixty eight.
Speaker 1 (03:32):
A good year for your listening.
Speaker 2 (03:34):
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.
Speaker 3 (03:46):
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?
Speaker 2 (04:03):
I was just that was my next question. Is Stacy
coming with you?
Speaker 3 (04:07):
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.
Speaker 2 (04:22):
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.
Speaker 1 (04:31):
Yeah.
Speaker 3 (04:31):
You made that talk with Maddie, which is really going
to be cool. You know, it's spiifying.
Speaker 2 (04:37):
Rocks dot com in front of a live audience.
Speaker 3 (04:40):
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.
Speaker 1 (04:47):
What are you doing?
Speaker 2 (04:48):
What are you doing? Especially because you've seeing my code right?
Speaker 1 (04:54):
Yeah? I know.
Speaker 3 (04:54):
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.
Speaker 2 (05:04):
You know, they haven't all been polished. I've had some clams.
Speaker 3 (05:09):
It's funny anyway, it's going to be a riot.
Speaker 2 (05:13):
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.
Speaker 3 (05:24):
No, you should have done the workshop called get Zamoran
running on your machine.
Speaker 2 (05:28):
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?
Speaker 1 (05:39):
Awesome? All right, what do you got?
Speaker 2 (05:48):
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?
Speaker 3 (06:10):
So it's a powerful I wonder what this does, carlus.
Speaker 2 (06:15):
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
(06:39):
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
(07:02):
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
(07:24):
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
(07:48):
tool for that.
Speaker 1 (07:49):
Awesome.
Speaker 2 (07:50):
Yeah, well that's what I got. Who's talking to us today?
Speaker 3 (07:52):
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.
Speaker 2 (08:09):
Wait a minute, what episode number was that.
Speaker 3 (08:10):
Fourteen seventy five, five hundred shows ago?
Speaker 2 (08:12):
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?
Speaker 1 (08:23):
No, please don't.
Speaker 3 (08:25):
All of that history is questionable at best.
Speaker 2 (08:27):
Yeah right.
Speaker 3 (08:28):
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
(08:50):
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
(09:13):
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
(09:35):
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.
Speaker 2 (09:43):
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
(10:05):
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
(10:28):
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,
(10:50):
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
(11:11):
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.
Speaker 1 (11:23):
Yeah.
Speaker 2 (11:24):
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.
Speaker 3 (11:35):
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
(11:57):
the famous photograph earth Rise by anders Yeah, and they
read from Genesis.
Speaker 1 (12:04):
Yeah.
Speaker 3 (12:04):
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
(12:25):
had finally were ahead on the space rice. They'd now
done something that the Soviets had not done.
Speaker 2 (12:30):
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
(12:51):
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,
(13:11):
the Egyptians perhaps or any of the ancient.
Speaker 3 (13:15):
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
(13:36):
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.
Speaker 1 (13:50):
It's the idea of.
Speaker 3 (13:52):
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.
Speaker 1 (14:10):
Wow.
Speaker 3 (14:10):
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
(14:31):
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
(14:55):
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
(15:16):
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.
(15:36):
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,
(15:56):
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.
Speaker 2 (16:08):
Wow, I can't imagine what the excitement must have been
like the audience.
Speaker 3 (16:13):
And that's the same year as we put humans around
the moon like sixty eight is horrible and astonishing.
Speaker 2 (16:21):
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
(16:42):
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
(17:03):
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.
Speaker 5 (17:13):
Lovely pronunciation by the way. Yeah, I'm trying you trying
Melbourne right as well?
Speaker 2 (17:19):
That's the Melbourne Nevin.
Speaker 5 (17:21):
Yeah, usually that's the trap. Yeah, thank you for having.
Speaker 3 (17:24):
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.
Speaker 5 (17:32):
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?
Speaker 1 (17:38):
Yeah? Right by the river right?
Speaker 2 (17:39):
Yeh. So I have a couple of Australian terms I'd
like to settle with you.
Speaker 5 (17:45):
Okay.
Speaker 2 (17:46):
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.
Speaker 5 (17:57):
I'm chuffed to be here, chuff to be here.
Speaker 2 (17:58):
And second one is you guys really don't put shrimp
on the bobbie.
Speaker 1 (18:03):
Do you know?
Speaker 5 (18:04):
I don't think I've ever seen anyone do that.
Speaker 2 (18:06):
And they don't say that, I mean, we don't call
it shrimp. No, that's an American.
Speaker 5 (18:09):
We would say prawns. Yeah, we would say prawns. And
even then, but on.
Speaker 2 (18:14):
The barbie, you don't do you say barbie or do
you say grill? Now we say bobby, you do say barbie? Okay?
Speaker 5 (18:19):
Oh yeah, we like to shorten everything.
Speaker 3 (18:21):
Yeah, yeah, even McDonald's is too long. It's mackers.
Speaker 5 (18:26):
Yes, absolutely, so.
Speaker 2 (18:27):
I remember Adam Cogan saying let's have some brecky not
breakfast hot eggs.
Speaker 5 (18:34):
That's right.
Speaker 2 (18:35):
And also Foster's beer is like water. You don't drink that.
Speaker 1 (18:38):
Stuff, right, Yeah, we don't drink that.
Speaker 5 (18:40):
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.
Speaker 2 (18:53):
So the American idea of Australia is nothing like Australia itself.
You just gotta go, yeah, got to go.
Speaker 5 (19:00):
The American idea of animals that will kill you. And
Appeck Steakhouse no.
Speaker 3 (19:06):
Yeah, yeah, I know Crocodile Dundee really and Outback Steakhouse
is owned by somebody from California.
Speaker 2 (19:12):
If I'm not mistaken, like you know, I would not
Australian at.
Speaker 5 (19:15):
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.
Speaker 2 (19:23):
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.
Speaker 5 (19:42):
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.
Speaker 2 (19:52):
Yeah.
Speaker 5 (19:52):
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
(20:14):
about eighteen months, almost exclusively.
Speaker 2 (20:17):
So yeah, well, why don't you remind us what that
was all about?
Speaker 5 (20:22):
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
(20:44):
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
(21:06):
bigger part of that, just you know, by its architecture,
it's more separated and things.
Speaker 3 (21:11):
It's cool and so stuff being built visual Studio being
brought to Visual Studio, code being brought to Visual Studio.
Speaker 1 (21:18):
I didn't know about that. That's interesting.
Speaker 5 (21:20):
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
(21:40):
Studio is the VS code one. They just reship it.
So it's a lovely architecture and when it works, it's great.
Speaker 3 (21:49):
And that's qualifier their David.
Speaker 2 (21:53):
Yeah, that was very polite, kind of almost Canadian way
to express your opinion about that.
Speaker 5 (21:59):
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
(22:19):
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
(22:41):
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
(23:03):
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
(23:24):
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
(23:45):
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
(24:06):
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
(24:28):
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.
(24:49):
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
(25:11):
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
(25:34):
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
(25:56):
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
(26:16):
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.
Speaker 2 (26:24):
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.
Speaker 5 (26:37):
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
(27:04):
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?
Speaker 2 (27:18):
For example?
Speaker 5 (27:19):
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
(27:40):
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.
(28:03):
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.
Speaker 2 (28:24):
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
(28:44):
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.
Speaker 5 (28:56):
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
(29:18):
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
(29:39):
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,
(30:01):
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
(30:23):
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
(30:44):
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.
Speaker 2 (30:56):
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.
Speaker 5 (31:18):
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,
(31:41):
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,
(32:01):
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.
Speaker 2 (32:09):
I don't know, but there's a reason that they chose
to do it that way, right, I mean.
Speaker 5 (32:14):
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,
(32:34):
we've got two systems for this, can we merge them?
And it certainly technically we can.
Speaker 2 (32:39):
It's just sure is it?
Speaker 5 (32:40):
How hard is it?
Speaker 2 (32:42):
Will we break?
Speaker 1 (32:43):
People?
Speaker 2 (32:43):
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.
Speaker 3 (32:51):
Easy, Yeah, definitely, and then all the places you'd go anyway, right.
Speaker 5 (32:57):
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.
Speaker 2 (33:13):
Wea code lens works in Visual studio, but not in
the Razor editor.
Speaker 5 (33:18):
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
(33:40):
Visual Studio client doesn't.
Speaker 3 (33:42):
And so that's on.
Speaker 5 (33:43):
Visual Studio to you know, move further towards embracing alix
per But they.
Speaker 1 (33:48):
Are doing that.
Speaker 5 (33:49):
Get busy they are doing.
Speaker 2 (33:54):
I'll let him know.
Speaker 5 (33:56):
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
(34:18):
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.
Speaker 2 (34:24):
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
(34:45):
and helps progressively extract code into micro services. Learn more
at aws dot Amazon dot com slash modernize.
Speaker 3 (34:57):
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
(35:19):
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.
Speaker 5 (35:28):
That issue is it lives on my book Macbarr in
my browser. I bet my that is my stream of
consciousness issue.
Speaker 3 (35:36):
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.
Speaker 5 (35:51):
Yes, I think itels like one left.
Speaker 3 (35:53):
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.
Speaker 5 (36:12):
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
(36:35):
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
(36:59):
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.
Speaker 1 (37:16):
And then.
Speaker 5 (37:18):
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
(37:40):
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
(38:02):
happened sometimes in that world. We were a little bit
isolated before.
Speaker 3 (38:05):
But sure, now your change in architecture is also added
by their changes in architecture.
Speaker 5 (38:10):
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
(38:32):
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
(38:53):
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.
Speaker 3 (39:01):
Yeah, you don't like big bangs, big bangs bad.
Speaker 5 (39:04):
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
(39:26):
in Visual Studio is the next big the next big hurdle,
So it's definitely exciting times definitely.
Speaker 1 (39:32):
Yeah.
Speaker 3 (39:32):
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.
Speaker 1 (39:41):
Anybody can look at it if they want to look out.
Speaker 5 (39:43):
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
(40:05):
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.
Speaker 2 (40:28):
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?
Speaker 5 (40:41):
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,
(41:02):
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,
(41:23):
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.
(41:45):
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
(42:07):
other things first. And it's not really well documented.
Speaker 2 (42:09):
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.
Speaker 5 (42:24):
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,
(42:46):
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
(43:09):
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
(43:30):
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
(43:51):
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,
(44:13):
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
(44:35):
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.
Speaker 1 (44:55):
You know.
Speaker 5 (44:55):
There's all these sorts of things we need to work through.
Speaker 1 (44:57):
But I'm hoping.
Speaker 5 (44:58):
I'm hoping this is a new foundation we can get
there from.
Speaker 2 (45:02):
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?
Speaker 5 (45:17):
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
(45:39):
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.
Speaker 2 (45:54):
But what a lot of times just closing the razor
file and reopening it, you know, gets rid of this
and recolors everything correctly.
Speaker 5 (46:02):
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
(46:24):
the past. The question is whether anyone will will notice,
because you know, when things are working.
Speaker 2 (46:30):
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.
Speaker 5 (46:39):
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
(47:03):
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,
(47:24):
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
(47:45):
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.
Speaker 2 (47:52):
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.
Speaker 5 (48:02):
Yeah, so yeah, that that should be a big win
as well.
Speaker 2 (48:06):
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
(48:28):
you want to talk about?
Speaker 5 (48:30):
I don't think so, you know, as I I could
talk about this stuff.
Speaker 2 (48:35):
For a while. You know, we're not pressed for time.
We have someone if you want to continue.
Speaker 3 (48:43):
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?
Speaker 5 (48:53):
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,
(49:16):
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.
Speaker 3 (49:33):
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.
Speaker 5 (49:48):
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
(50:11):
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,
(50:32):
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
(50:55):
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,
(51:17):
we need to add in the newer style.
Speaker 2 (51:20):
Good stuff. What's next for you, David? What's in your inbox?
Your to do list?
Speaker 5 (51:27):
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
(51:49):
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.
Speaker 2 (51:56):
That's great.
Speaker 3 (51:57):
Take the preview out for us bin try this on.
Speaker 2 (52:00):
Yeah, absolutely absolutely, I'm looking forward to it. Yeah, okay, Well,
thanks very much for spending the hour with us.
Speaker 1 (52:07):
David.
Speaker 2 (52:08):
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
(52:40):
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,
(53:03):
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.
Speaker 5 (53:18):
You got jud Middle Vans
Speaker 1 (53:22):
And the
Hey Richard, Hey Carl, what do you know?
Speaker 2 (00:03):
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.
Speaker 1 (00:11):
What is it?
Speaker 3 (00:12):
It's cybersecurity Intersection. Let's let Michelle tell that story.
Speaker 4 (00:16):
Hey Michelle, Hey Carl, Hey Richard, how are you.
Speaker 2 (00:21):
Tell us about cybersecurity Intersection?
Speaker 4 (00:23):
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
(00:43):
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
(01:03):
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
(01:26):
production operations keep them secure. So it's an amazing group
of speakers, really excited about it.
Speaker 2 (01:31):
And I think I can count myself among the group
of speakers there.
Speaker 4 (01:35):
Well, yes you can. That is great.
Speaker 2 (01:37):
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.
Speaker 4 (01:48):
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
(02:10):
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.
Speaker 3 (02:23):
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.
Speaker 4 (02:42):
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.
Speaker 2 (03:04):
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
(03:27):
Kemp and we're here for episode number nineteen hundred and
sixty eight.
Speaker 1 (03:32):
A good year for your listening.
Speaker 2 (03:34):
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.
Speaker 3 (03:46):
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?
Speaker 2 (04:03):
I was just that was my next question. Is Stacy
coming with you?
Speaker 3 (04:07):
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.
Speaker 2 (04:22):
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.
Speaker 1 (04:31):
Yeah.
Speaker 3 (04:31):
You made that talk with Maddie, which is really going
to be cool. You know, it's spiifying.
Speaker 2 (04:37):
Rocks dot com in front of a live audience.
Speaker 3 (04:40):
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.
Speaker 1 (04:47):
What are you doing?
Speaker 2 (04:48):
What are you doing? Especially because you've seeing my code right?
Speaker 1 (04:54):
Yeah? I know.
Speaker 3 (04:54):
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.
Speaker 2 (05:04):
You know, they haven't all been polished. I've had some clams.
Speaker 3 (05:09):
It's funny anyway, it's going to be a riot.
Speaker 2 (05:13):
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.
Speaker 3 (05:24):
No, you should have done the workshop called get Zamoran
running on your machine.
Speaker 2 (05:28):
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?
Speaker 1 (05:39):
Awesome? All right, what do you got?
Speaker 2 (05:48):
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?
Speaker 3 (06:10):
So it's a powerful I wonder what this does, carlus.
Speaker 2 (06:15):
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
(06:39):
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
(07:02):
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
(07:24):
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
(07:48):
tool for that.
Speaker 1 (07:49):
Awesome.
Speaker 2 (07:50):
Yeah, well that's what I got. Who's talking to us today?
Speaker 3 (07:52):
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.
Speaker 2 (08:09):
Wait a minute, what episode number was that.
Speaker 3 (08:10):
Fourteen seventy five, five hundred shows ago?
Speaker 2 (08:12):
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?
Speaker 1 (08:23):
No, please don't.
Speaker 3 (08:25):
All of that history is questionable at best.
Speaker 2 (08:27):
Yeah right.
Speaker 3 (08:28):
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
(08:50):
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
(09:13):
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
(09:35):
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.
Speaker 2 (09:43):
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
(10:05):
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
(10:28):
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,
(10:50):
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
(11:11):
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.
Speaker 1 (11:23):
Yeah.
Speaker 2 (11:24):
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.
Speaker 3 (11:35):
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
(11:57):
the famous photograph earth Rise by anders Yeah, and they
read from Genesis.
Speaker 1 (12:04):
Yeah.
Speaker 3 (12:04):
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
(12:25):
had finally were ahead on the space rice. They'd now
done something that the Soviets had not done.
Speaker 2 (12:30):
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
(12:51):
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,
(13:11):
the Egyptians perhaps or any of the ancient.
Speaker 3 (13:15):
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
(13:36):
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.
Speaker 1 (13:50):
It's the idea of.
Speaker 3 (13:52):
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.
Speaker 1 (14:10):
Wow.
Speaker 3 (14:10):
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
(14:31):
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
(14:55):
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
(15:16):
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.
(15:36):
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,
(15:56):
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.
Speaker 2 (16:08):
Wow, I can't imagine what the excitement must have been
like the audience.
Speaker 3 (16:13):
And that's the same year as we put humans around
the moon like sixty eight is horrible and astonishing.
Speaker 2 (16:21):
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
(16:42):
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
(17:03):
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.
Speaker 5 (17:13):
Lovely pronunciation by the way. Yeah, I'm trying you trying
Melbourne right as well?
Speaker 2 (17:19):
That's the Melbourne Nevin.
Speaker 5 (17:21):
Yeah, usually that's the trap. Yeah, thank you for having.
Speaker 3 (17:24):
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.
Speaker 5 (17:32):
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?
Speaker 1 (17:38):
Yeah? Right by the river right?
Speaker 2 (17:39):
Yeh. So I have a couple of Australian terms I'd
like to settle with you.
Speaker 5 (17:45):
Okay.
Speaker 2 (17:46):
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.
Speaker 5 (17:57):
I'm chuffed to be here, chuff to be here.
Speaker 2 (17:58):
And second one is you guys really don't put shrimp
on the bobbie.
Speaker 1 (18:03):
Do you know?
Speaker 5 (18:04):
I don't think I've ever seen anyone do that.
Speaker 2 (18:06):
And they don't say that, I mean, we don't call
it shrimp. No, that's an American.
Speaker 5 (18:09):
We would say prawns. Yeah, we would say prawns. And
even then, but on.
Speaker 2 (18:14):
The barbie, you don't do you say barbie or do
you say grill? Now we say bobby, you do say barbie? Okay?
Speaker 5 (18:19):
Oh yeah, we like to shorten everything.
Speaker 3 (18:21):
Yeah, yeah, even McDonald's is too long. It's mackers.
Speaker 5 (18:26):
Yes, absolutely, so.
Speaker 2 (18:27):
I remember Adam Cogan saying let's have some brecky not
breakfast hot eggs.
Speaker 5 (18:34):
That's right.
Speaker 2 (18:35):
And also Foster's beer is like water. You don't drink that.
Speaker 1 (18:38):
Stuff, right, Yeah, we don't drink that.
Speaker 5 (18:40):
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.
Speaker 2 (18:53):
So the American idea of Australia is nothing like Australia itself.
You just gotta go, yeah, got to go.
Speaker 5 (19:00):
The American idea of animals that will kill you. And
Appeck Steakhouse no.
Speaker 3 (19:06):
Yeah, yeah, I know Crocodile Dundee really and Outback Steakhouse
is owned by somebody from California.
Speaker 2 (19:12):
If I'm not mistaken, like you know, I would not
Australian at.
Speaker 5 (19:15):
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.
Speaker 2 (19:23):
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.
Speaker 5 (19:42):
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.
Speaker 2 (19:52):
Yeah.
Speaker 5 (19:52):
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
(20:14):
about eighteen months, almost exclusively.
Speaker 2 (20:17):
So yeah, well, why don't you remind us what that
was all about?
Speaker 5 (20:22):
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
(20:44):
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
(21:06):
bigger part of that, just you know, by its architecture,
it's more separated and things.
Speaker 3 (21:11):
It's cool and so stuff being built visual Studio being
brought to Visual Studio, code being brought to Visual Studio.
Speaker 1 (21:18):
I didn't know about that. That's interesting.
Speaker 5 (21:20):
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
(21:40):
Studio is the VS code one. They just reship it.
So it's a lovely architecture and when it works, it's great.
Speaker 3 (21:49):
And that's qualifier their David.
Speaker 2 (21:53):
Yeah, that was very polite, kind of almost Canadian way
to express your opinion about that.
Speaker 5 (21:59):
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
(22:19):
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
(22:41):
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
(23:03):
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
(23:24):
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
(23:45):
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
(24:06):
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
(24:28):
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.
(24:49):
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
(25:11):
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
(25:34):
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
(25:56):
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
(26:16):
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.
Speaker 2 (26:24):
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.
Speaker 5 (26:37):
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
(27:04):
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?
Speaker 2 (27:18):
For example?
Speaker 5 (27:19):
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
(27:40):
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.
(28:03):
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.
Speaker 2 (28:24):
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
(28:44):
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.
Speaker 5 (28:56):
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
(29:18):
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
(29:39):
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,
(30:01):
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
(30:23):
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
(30:44):
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.
Speaker 2 (30:56):
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.
Speaker 5 (31:18):
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,
(31:41):
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,
(32:01):
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.
Speaker 2 (32:09):
I don't know, but there's a reason that they chose
to do it that way, right, I mean.
Speaker 5 (32:14):
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,
(32:34):
we've got two systems for this, can we merge them?
And it certainly technically we can.
Speaker 2 (32:39):
It's just sure is it?
Speaker 5 (32:40):
How hard is it?
Speaker 2 (32:42):
Will we break?
Speaker 1 (32:43):
People?
Speaker 2 (32:43):
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.
Speaker 3 (32:51):
Easy, Yeah, definitely, and then all the places you'd go anyway, right.
Speaker 5 (32:57):
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.
Speaker 2 (33:13):
Wea code lens works in Visual studio, but not in
the Razor editor.
Speaker 5 (33:18):
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
(33:40):
Visual Studio client doesn't.
Speaker 3 (33:42):
And so that's on.
Speaker 5 (33:43):
Visual Studio to you know, move further towards embracing alix
per But they.
Speaker 1 (33:48):
Are doing that.
Speaker 5 (33:49):
Get busy they are doing.
Speaker 2 (33:54):
I'll let him know.
Speaker 5 (33:56):
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
(34:18):
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.
Speaker 2 (34:24):
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
(34:45):
and helps progressively extract code into micro services. Learn more
at aws dot Amazon dot com slash modernize.
Speaker 3 (34:57):
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
(35:19):
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.
Speaker 5 (35:28):
That issue is it lives on my book Macbarr in
my browser. I bet my that is my stream of
consciousness issue.
Speaker 3 (35:36):
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.
Speaker 5 (35:51):
Yes, I think itels like one left.
Speaker 3 (35:53):
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.
Speaker 5 (36:12):
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
(36:35):
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
(36:59):
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.
Speaker 1 (37:16):
And then.
Speaker 5 (37:18):
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
(37:40):
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
(38:02):
happened sometimes in that world. We were a little bit
isolated before.
Speaker 3 (38:05):
But sure, now your change in architecture is also added
by their changes in architecture.
Speaker 5 (38:10):
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
(38:32):
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
(38:53):
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.
Speaker 3 (39:01):
Yeah, you don't like big bangs, big bangs bad.
Speaker 5 (39:04):
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
(39:26):
in Visual Studio is the next big the next big hurdle,
So it's definitely exciting times definitely.
Speaker 1 (39:32):
Yeah.
Speaker 3 (39:32):
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.
Speaker 1 (39:41):
Anybody can look at it if they want to look out.
Speaker 5 (39:43):
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
(40:05):
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.
Speaker 2 (40:28):
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?
Speaker 5 (40:41):
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,
(41:02):
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,
(41:23):
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.
(41:45):
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
(42:07):
other things first. And it's not really well documented.
Speaker 2 (42:09):
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.
Speaker 5 (42:24):
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,
(42:46):
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
(43:09):
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
(43:30):
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
(43:51):
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,
(44:13):
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
(44:35):
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.
Speaker 1 (44:55):
You know.
Speaker 5 (44:55):
There's all these sorts of things we need to work through.
Speaker 1 (44:57):
But I'm hoping.
Speaker 5 (44:58):
I'm hoping this is a new foundation we can get
there from.
Speaker 2 (45:02):
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?
Speaker 5 (45:17):
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
(45:39):
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.
Speaker 2 (45:54):
But what a lot of times just closing the razor
file and reopening it, you know, gets rid of this
and recolors everything correctly.
Speaker 5 (46:02):
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
(46:24):
the past. The question is whether anyone will will notice,
because you know, when things are working.
Speaker 2 (46:30):
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.
Speaker 5 (46:39):
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
(47:03):
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,
(47:24):
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
(47:45):
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.
Speaker 2 (47:52):
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.
Speaker 5 (48:02):
Yeah, so yeah, that that should be a big win
as well.
Speaker 2 (48:06):
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
(48:28):
you want to talk about?
Speaker 5 (48:30):
I don't think so, you know, as I I could
talk about this stuff.
Speaker 2 (48:35):
For a while. You know, we're not pressed for time.
We have someone if you want to continue.
Speaker 3 (48:43):
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?
Speaker 5 (48:53):
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,
(49:16):
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.
Speaker 3 (49:33):
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.
Speaker 5 (49:48):
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
(50:11):
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,
(50:32):
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
(50:55):
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,
(51:17):
we need to add in the newer style.
Speaker 2 (51:20):
Good stuff. What's next for you, David? What's in your inbox?
Your to do list?
Speaker 5 (51:27):
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
(51:49):
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.
Speaker 2 (51:56):
That's great.
Speaker 3 (51:57):
Take the preview out for us bin try this on.
Speaker 2 (52:00):
Yeah, absolutely absolutely, I'm looking forward to it. Yeah, okay, Well,
thanks very much for spending the hour with us.
Speaker 1 (52:07):
David.
Speaker 2 (52:08):
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
(52:40):
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,
(53:03):
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.
Speaker 5 (53:18):
You got jud Middle Vans
Speaker 1 (53:22):
And the
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Burden
The Burden is a documentary series that takes listeners into the hidden places where justice is done (and undone). It dives deep into the lives of heroes and villains. And it focuses a spotlight on those who triumph even when the odds are against them. Season 5 - The Burden: Death & Deceit in Alliance On April Fools Day 1999, 26-year-old Yvonne Layne was found murdered in her Alliance, Ohio home. David Thorne, her ex-boyfriend and father of one of her children, was instantly a suspect. Another young man admitted to the murder, and David breathed a sigh of relief, until the confessed murderer fingered David; “He paid me to do it.” David was sentenced to life without parole. Two decades later, Pulitzer winner and podcast host, Maggie Freleng (Bone Valley Season 3: Graves County, Wrongful Conviction, Suave) launched a “live” investigation into David's conviction alongside Jason Baldwin (himself wrongfully convicted as a member of the West Memphis Three). Maggie had come to believe that the entire investigation of David was botched by the tiny local police department, or worse, covered up the real killer. Was Maggie correct? Was David’s claim of innocence credible? In Death and Deceit in Alliance, Maggie recounts the case that launched her career, and ultimately, “broke” her.” The results will shock the listener and reduce Maggie to tears and self-doubt. This is not your typical wrongful conviction story. In fact, it turns the genre on its head. It asks the question: What if our champions are foolish? Season 4 - The Burden: Get the Money and Run “Trying to murder my father, this was the thing that put me on the path.” That’s Joe Loya and that path was bank robbery. Bank, bank, bank, bank, bank. In season 4 of The Burden: Get the Money and Run, we hear from Joe who was once the most prolific bank robber in Southern California, and beyond. He used disguises, body doubles, proxies. He leaped over counters, grabbed the money and ran. Even as the FBI was closing in. It was a showdown between a daring bank robber, and a patient FBI agent. Joe was no ordinary bank robber. He was bright, articulate, charismatic, and driven by a dark rage that he summoned up at will. In seven episodes, Joe tells all: the what, the how… and the why. Including why he tried to murder his father. Season 3 - The Burden: Avenger Miriam Lewin is one of Argentina’s leading journalists today. At 19 years old, she was kidnapped off the streets of Buenos Aires for her political activism and thrown into a concentration camp. Thousands of her fellow inmates were executed, tossed alive from a cargo plane into the ocean. Miriam, along with a handful of others, will survive the camp. Then as a journalist, she will wage a decades long campaign to bring her tormentors to justice. Avenger is about one woman’s triumphant battle against unbelievable odds to survive torture, claim justice for the crimes done against her and others like her, and change the future of her country. Season 2 - The Burden: Empire on Blood Empire on Blood is set in the Bronx, NY, in the early 90s, when two young drug dealers ruled an intersection known as “The Corner on Blood.” The boss, Calvin Buari, lived large. He and a protege swore they would build an empire on blood. Then the relationship frayed and the protege accused Calvin of a double homicide which he claimed he didn’t do. But did he? Award-winning journalist Steve Fishman spent seven years to answer that question. This is the story of one man’s last chance to overturn his life sentence. He may prevail, but someone’s gotta pay. The Burden: Empire on Blood is the director’s cut of the true crime classic which reached #1 on the charts when it was first released half a dozen years ago. Season 1 - The Burden In the 1990s, Detective Louis N. Scarcella was legendary. In a city overrun by violent crime, he cracked the toughest cases and put away the worst criminals. “The Hulk” was his nickname. Then the story changed. Scarcella ran into a group of convicted murderers who all say they are innocent. They turned themselves into jailhouse-lawyers and in prison founded a lway firm. When they realized Scarcella helped put many of them away, they set their sights on taking him down. And with the help of a NY Times reporter they have a chance. For years, Scarcella insisted he did nothing wrong. But that’s all he’d say. Until we tracked Scarcella to a sauna in a Russian bathhouse, where he started to talk..and talk and talk. “The guilty have gone free,” he whispered. And then agreed to take us into the belly of the beast. Welcome to The Burden.