 Hold on. We're trying to set up the audio over here Against thank you everybody. We're set up. We're setting up a new machine With a little more power To get us through the remainder of the evening Jeff Fritz is doing an amazing job Being the AV guy. Oh, thank you, Jamie Yeah, Jamie Singleton also being my co-host or where we're not co-hosts. We are the host Together, that's right So we're trying to figure this out and we have as you can see we have David and already ready to go We obviously just you can't hear him you guys that stop sharing So we're just figuring out the audio pieces and we should be ready to get rock and roll Yeah, the mics are on We're just live in the studio. That's right. The rain in Spain falls mainly in the plane Not so good for everybody. I know I could do You can do a couple jokes Jeff is up very late tonight. Yes, a rock star So hey, so all of you who are watching right now are these hearing us right now You guys need to check out Jeff shell He broadcasts through the visual studio channel as well Dad jokes. Oh, we can do some dad jokes too. That's awesome. You know the best part about UDP jokes Is I don't care if you get him or not Come on at least there's one of you geeks out there that found that I'm using There we go, thank you King demo there Let's see how many speakers there we go ha Oh, that's funny that fell into a static boy boom boom The device isn't used by another application We can see the slide deck now over here. I don't know we're gonna try this out Hey, there it is. You guys can see my Skype now. Oh The answer for Clark isle or Clark you it is always spaces Unless you set your tabs to be always four spaces Then that's okay, too So the questions here is is do we do K and R because that's the only way to really code You know God who scream of death is the best scream of death. I love that Should we just go to the other machine thing or yeah, let's go back. Okay? We are going to punt to the other machine. We don't know what's going on We'll be right back. We'll be right back. All right. Thank you. So I read that everybody But I think we're we're alive now Hi, my name is David Gardner. I'm a dotnet developer based in Adelaide, South Australia. So There is an Australian accent Do sort of call me up if there's anything I say that you don't understand my talk today is on Packaging and projects and the new project system And how we can use that even if you're using dotnet framework projects so this is all related to the New project system that first shipped with dotnet core and if we jump over to The right browser window So this is based on github. It's an open source project and You can see it's quite an active project. There's stuff happening there all the time the new project system was created Really because the old project system which was written for sort of C sharp and visual basic projects was really tied to visual studio So we're only going to work on Windows. So for cross-platform support They needed to come up with something new and it's also given an opportunity to To sort of rethink how it's all implemented makes some performance improvements So do you have a look at the github site? There's some good documentation on here on what really makes up the project system and also things like a feature comparison What what things are in the new product system that aren't in the old one and vice versa? What hasn't been brought into the new one yet and And also yeah, just get an idea of what releases are going to have those features as well It is open source. So you can even jump in and add some Requests for features and maybe even commit a pull request as well. So the new product system Well, let's have a look and see how we can actually Migrate an existing project to use that. I'm going to jump over to visual studio So I've got a solution opened here. It's actually The source code for chocolate ease Choco dot xe command line tool. So chocolate is a Platform for installing software on a Windows PC. It's a bit like apt-get for Linux, but on the Windows platform And so I've downloaded the source code for their command line tool And I'm going to demonstrate upgrading the chocolatey class library to using the new project system format The first thing we can do and I'll just switch over to VS code just to show you what that looks like I've got so many windows here Ah Well, sorry So here's the project file for chocolate the moment if you've ever looked at a CS prod or a VB prod It'll look pretty familiar. We've got things like assembly references We've got every source file is listed there individually That's part of this particular library. We've got other things like embedded resources and and Project references and a few other bits and pieces as well. So that whole file there is around about 371 lines long Okay, let me go out the way So the first thing we can do is just a small thing. We've got new get package references here And so one thing we can do is actually migrate those to use the new package reference format And one way we can do that is to use a little wizard that should normally pop up here in this menu and I right click on the References node if it doesn't then just open up your package manager console window and by allowing that to happen Then that menu item will appear. So just if you don't see it You just need to do that step first is to initialize it We then see all the current list of packages that we're using in this project We'll also see a couple here that have been put under the transitive dependencies Section and what that means is that these two packages. We're currently referencing those but we don't need to Going forwards because they're actually dependencies of RX link and so we don't need to directly depend on these RX link is going to bring them in for us. You can choose to still depend on them if you want But we don't need to so I'm going to hit okay It's going to uninstall those packages from packages.config and It's going to Bring up a little log file to say what it's done Close that and close this file, which I think was to do with uninstalling the packages And so now I'll hit save and so our project still there. I'll switch back to VS code too many things open Where's it gone? There it is. Sorry, and we'll see down the bottom of the file here We now have a new item group there with package reference So I still haven't converted the rest of the project But we can already start using package reference here rather than packages.config and so we're already making use of The transient dependency so we only need to reference RX link in this case and we're getting those other two packages in So our line count is down a little bit. I'm just going to copy That in the one clipboard because we're going to use that in a second and Back to the project now. So we've done that up. Let's keep going and I'm just going to jump over and the next thing We do is actually convert the Project itself to the new format and one easy way of doing that is to use a command line tool so And we can use .net the command line tool out to create a new project files I'm going to a .net new class lib and the name is going to be chocolatey But hit enter on that. It's actually going to complain and say hang on that file already exists. Are you sure and I'll say yes? I am so I'll run that and That's created a new project file. I switch back to VS code and We'll see that now our project folders really small. That's fantastic Possibly even a bit too small by default it sets the target framework as net standard to zero But our project was actually targeting dot net 4.0. So I'll change the target back Because we're not ready to migrate our code base to dot net standard yet I can paste back in my package references Because they're going to work as well. Now switch back to Visual Studio and you'll notice. Yep, that project's changed I need to reload it And Here we go, and it looks pretty much the same So we've still got all that source code files there and now I can right click on my project and I can edit the project Without having to unload it. So that is a great feature of the new project system We don't have to unload edit reload and wait forever. We can edit the project file live. That's fantastic We've got our project references there. So if I expand this new dependencies node here I can see mine you get packages there all nicely and we can even see those transitive dependencies There's those other two packages underneath Rx link. That's looking good. So what else do we need to do? So normally you'd probably use your version control and do a diff between the old project the new project to To figure out what things you do need to bring back in here. So I've got my package references done. I also have some Regular assembly references some of these are to framework assemblies and some of those are to other libraries that are in my source code repository, so I'll bring those in and just hit save and then the other thing I need is At the moment, you'll notice we've got all the files Are included in the project. We don't need to list them anymore Because by default the new project system includes every file that's under the directory of that project file But in this case the old project was also linking to a file outside of that directory hierarchy So I do need to bring that in and so that was this file here The other thing you'll notice is we've actually got a new file here. So when I created that project file it also created a Just a placeholder class file. I'm going to delete that and One thing to keep in mind is that because the project system now is including every five-order fault That means if you had any files in your old project that were on in sort of version control or on the disk, but Not in the project. So you excluded those from the project. They're going to suddenly Reappear in the project. So it may be that before you do this kind of migration you clean up all those files first just to avoid Any problems with them sort of reappearing in the project Okay, so we've got our solution file there The and so one more thing we need to do a couple more things is we need to add a project reference back That was in the old project. So I could just go in here and use the GUI for that one And we'll see that just added a project reference element there The other thing we had if you remember quickly when I looked at the original project file There was some embedded resources there. So I better put them back in because by default Files that are not source code files for example this config file have a build action of none. So I'll change that to embedded resource and hit save and we'll just jump back to the project file and see what happened there So by default any other file is added to the none item group And so by changing that to embedded resource It's added this line here Which is we're going to remove that file from the none group and then down the bottom It's going to add that file into the embedded resource group like that I've got a few other files. I need to do the same for that. So I'll just find those and They're under here So again, I could just use a diff tool and just sort of copy those over from the old version if I knew Which ones Needed to go over there change them to a better resource. Okay, that should be pretty much it Let's try and build this project and see how we go and We got an error Okay, so what was that error? I'll bring up the error list so we can see it there as well It's complaining that we've got a duplicate of all these attributes. So what's going on there? I'm just going to grab that out of there. So it turns out the new project system Has it that's a nice feature so let's just find where those attributes are declared at the moment So normally you'd often declare those attributes in your assembly info file If I open that actually there's no attributes declared there, but there was that linked file that I added in let's have a look at that one and Sure enough, yes, that's where they're being declared But they're only declared once so where's this duplicate coming from or the new product system actually generates these for you You don't need to define them yourself if you don't want to However, in this case, I've already got them here. I don't want the project system to do that So how do I turn that off? Well, you can just set a property in your project file So I'll come back up here and set that to false and if I build my project now Let's say yep, that error is gone. So that's good. So we just had at the same Properties for all the other attributes because we've got them already there drop them in and now if I build Oh good. And so in fact if I build the solution and Jump back to my PowerShell window. I think I might even be able to run the console application. So In debug Choco See if that works and it does. So there you go. We've managed to migrate one of our Projects in this solution to the new format. We'll switch back and actually we don't need to do that So we're now down to about 75 lines from about 360 I think it was before so our project file is a lot more compact and The nice thing is because we're not including every source file in this project It means that if you're adding new files or removing them, you're not going to be modifying this file So just one less thing to worry about merge conflicts Okay, well we here we added some package references in there There's some other nice things we can do with package references. One of the things is we can Use floating version numbers. So you might think well actually I'm happy to take whatever is the latest version of Rx link 2.1 dot the highest number that's out now, or you might be really brave and go Yep, whatever version 2 is I want I want that one and I want the latest one of that And actually if we hit save on that We'll notice that the build system goes away Thanks for a bit and then realize actually the latest one is 2.2.5 So it's able to to load that in pretty quickly But that's even quicker because I've already done this before so things that cached on my computer We're looking at this and we're thinking that's good And it's nice how we've got our version numbers here But if I've got a solution with a lot of projects and I want to upgrade a package That's still going to impact a whole lot of projects with changing all the version numbers So wouldn't it be nice if I could centralize How I'm versioning all my packages. Well, yes, it would so let's jump back to VS code And I'm going to create a new file here under my solution and I'm going to call that file directory dot build dot targets and This is an MS build file. So I'm going to make the root element project I'm just going to paste in I don't group that is copied out of my other project and I'm just going to change where it says include. I'm going to change that to update and hit save and by doing this That file is now picked up by the the project system And it means I don't need to specify my versions here anymore And in fact, I could go through and delete all of those And I'll do that actually Get rid of that one and I'll bring in a new one Which is a little bit more succinct So now and we can see that in fact the version numbers are still getting picked up in visual studio here it it's loading that directory dot build dot targets file and Including that with each project file under the solution So you can also have a directory dot build dot props file which is sort of prepended to each project and the targets The L file is sort of appended to each project and the syntax the L switch back to that file Really is that rather than include we've got an update. So this is going to find any Items in the package reference item group with this name and it's going to set the Version metadata to two dot one dot three and so that's how we're able to still have these version numbers here So now with that one file I can centralize all the version numbers for my packages One thing to be aware of with that though is It's very convenient for managing versions the the tooling in visual studio I can still go in and say manage when you get packages to to see if there's updates But if I try and apply those updates, it doesn't know how to update directory dot build dot targets So you'll you'll still want to go in and manually update Those that file if you want to do a package update Okay, moving on Another thing with our project file while we're up here is the SDK attribute This is a new addition to the the project file format and you'll notice that we have Microsoft net dot SDK there So that's the sort of default value that was created for us If you create a unit test project, it'll have a slightly different name there But the interesting thing is that this name we can put other values in there And so for one example of that I'll switch over to my browser. And so another Developer quite well known in the dotnet community. Orin Novotny has created a Package called MS build dot SDK extras And so this is a new get package And if you use that name with that SDK attribute then you it will download this package And or add some extra functionality that that Orin's implemented. So in this case this package does Generate reference assembly. So if you're creating sort of class libraries Are they gonna be people gonna be using that may be something of interest But also just to see how Orin has managed to to extend the project system with a custom SDK Cool Alright, so we've seen how to generate A migrator project and that's all worked really well. I'm now going to show you a few little areas where in Me doing this I've encountered some some differences in how the old project system a new product system work so the first one of those is Looking at Generating files as part of the build process and how they're included So this is something I've seen in a couple of different places where you have a project or a solution where The app.config file is not committed to version control and so Essentially because every developer has their own Connection string and their own preference for logging and so to avoid everybody fighting over an overriding everyone else's config We don't commit the app config Don't know what keeps doing that We commit another file and in the project file We have a build step that just checks see if there's no app config then I'm going to copy the app default config To app config if there is one I'll just leave it alone So that allows the developers to have their own customized settings in this file and Sort of work and everyone's happy one thing I did notice though is if I open this Folder here and we look in the build output folder is There's an xc and a pdb, but there's no xc.config file there now if I built this project again Then it would create one, but the first time it didn't so if I delete that app config and do a build We'll see that Yep, there's still no config file there So how can we make sure that first time around that the the config gets copied out correctly? So what I discovered was Presumably just a slight change in the sequence in which things happen in the new product system I just need to include this line here to say that when we do do a copy We just update the nun group with that file and then the build system is able to pick that up later on and generate that so File again, we'll Build our project again and we've got our config file back So that's good So that's just one little thing that I need to do just to to make things work properly Particularly you might want to use this Because even that that first time is something that would probably happen on the build server. So something to be aware of Okay, the other thing That I noticed is That and you may have noticed this too already is that the output path for new product system projects is slightly different so I've got two console applications here. I'll run the first one. It's a very simple application It just looks for a file loads that file and just outputs some content from that file Which happens to be the program.cs file. So not that exciting That's using the old product system the same application migrated to the new project system we'll run that one and We actually get an exception it failed it couldn't find the file to open it and the reason is that Under the new product system, it's not just bin slash debug. It's bin Debug and also by default the the target framework name So there's our XE there and for most of the time that's that's quite reasonable and one advantage of that is actually It one of the reasons that they did that was because you can Target multiple frameworks. So I can go in here. It was actually I want to target .NET 4.5 and .NET 4.5 4.7 and so it needs two different directories to output those two But if you're migrating a sort of a legacy application, I've seen this in some unit test libraries that I've worked on where they're loading data files from the project itself and so one way to To go back to the old wave Output path is to set this property here pen target framework to output path set that to false and then things should work if I rebuild that application and press F5 Everything works again. So normally you wouldn't do that But just in rather than having to update all the logic in this Application straight away. I can set that and then sort of move on there I can come back and make that and that sort of update the code later on if I want to Okay All right, we've seen a couple of things with sort of dealing with Sort of differences in the the project system We're now going to move on to a new get packages. So both consuming them and creating them. So in this example here We've got some new get packages. So two class libraries that I'm going to that are creating new get packages I've got two console applications that are consuming those new get packages. So I'm not using project references I'm using package references here The old ones are using the old product system the new projects or the not old ones are using the new product system and so here I've got my old class library, I've got a Text file there and that's being added in as content in that new get package and in the old Application sure enough the package that file from that package has been included in this project And it is there under the project file However, the new Project system project is also referencing that package, but it doesn't have a text file one there The reason is that there's been a change with that with using package references that any content You know as in files that are using the content target are not Included in a new product system project So they anything like that needs to be updated to use Content files target and so the example in this project. I'll open up The project file is that we've got our text file new here So it's not only going in content so we can still work with older projects But any new product system needs to be under content files And this also shows that we can generate a new get package from the project file And we don't need to have a separate new spec file So we have a generate package on build property set to true. So every time we build this library It's also going to create a new get package If you can't remember what that setting is then just open up the project properties And you'll see there's a package tab here and that corresponds to this option the generate new get package on build There's also all these other fields that you can fill in that are all the Values that are the metadata that's going to be added to the the package as well So you can fill those in so that you don't need to have a new spec file necessarily To generate a new get package, which is another nice optimization one last thing to worry about So if I using that package and I'm using it in a project that's also using the new product system We'll see that this text file new We've sort of said that that Should appear under the special directory so in this project here sure enough There's our special directory and there's our text file new And one other thing to be aware of if we hover down here. It doesn't quite show up So I'll just select that value. This is the path to where that actual file is It's not located under our project anymore. It's actually located under my user profile So be aware of that that the new product system package references the packages are unpacked in this directory Under the user's profile be that the the developer or the the account that your build server is running at So that means again if you've got code that's making assumptions about where these files end up You're gonna have to change that code and so again, I've encountered this where was using new get packages to to wrap Backpack database files for use with Integration tests and so I had to change those packages to be able to find where those files were so that we could run those against the database All right moving on another scenario I've got a Solution here and I've got a class lobby that I'm creating a new get package for because this class lobby has some Fantastic business logic in it. I'm pretty sure that this business logic is so good because it's it's bug-free I'm pretty confident of that and I'm sure the other developers in my company are gonna want to use this because they love bug-free code But I'm also using this as a project reference for this tool that I've got here that's doing some fantastic stuff and So this is a new get package tool So I'll show you in the project file. I'm using is tool equals true I want to package this up and distribute it as a new get package, but it's an XC and So if I do that I'll do build and I'll show you there's some problems here that if I go to File Explorer will open up that package Using the new get package Explorer Okay, so it's a tool project. So it's gonna put things under the tools directory But we've only got the XC. We don't have the the linked assembly that we're also depending on with that fantastic business logic in it We've also Added a dependency here. We're depending on this other package, but we're a tool package We don't want that we should all be self-contained. So how can we fix that? so let's go back here and first of all to Bring in that ref that project reference. We need to hook into the the build process here So I'm just gonna uncomment this line which allows us to hook this extra build target in and This build target just goes through any project references and make sure that we're copying Any of those project references to our package output? The second thing I want to do is remove that package dependency because we don't want that for a tool package So there's a private assets property that I can set For the project reference I'm gonna set that to all what that does is it means that as far as new get goes this reference I'm using it, but no one else needs to know about it You can also see this through the GUI if you expand dependencies and Projects and down here in the properties. You'll also see private assets include assets So if I hit save then We should see that down there Okay, if I hit run I'm gonna rebuild everything and Just feel like I'm gonna do it again. If I go back open up that package again. I'm hoping That now I don't have any other dependencies and in my tools I've got both my assembly and the XE So that's what I want. That's good Okay moving on Okay, different scenario now. We've got a new get package and My developers that are using my package, they'd like to have a better experience using that package as far as if something goes wrong it'll be nice if they had other PDB's and Previously you would have said David don't include PDB's in the new get package because they're so massive and they just make it so big But we now have portable PDB's and a portal PDB is a lot smaller So it is conceivable to include that in the package itself And I'll show you what I mean in this example here. I've got a Library and the library itself is 4k and the PDB is only 1k So rather than the debugging symbols the PDB files being much larger than the Output assemblies. They're actually generally a lot smaller now. So adding that to a new get package is no big drama so we can do that and So if we edit our class library, we just need to change a property here To say I don't just want to include the DLL. I also want to include the dot PDB as well And I'll just increment my version number For the package as well so that we can do that I'm going to rebuild I'm just going to rebuild that package and Then we'll switch back To here and so I've now got there's my package. I'll just open that up just to show you that we do actually have Both the DLL and the PDB there. That's good And now just to also prove I've got nothing up my sleeve. I'm just going to delete That directory I'm going to come back down here. I'm going to delete Object in the C sharp source code for that as well. I'm going to come back to the project. I'm going to remove that library from the solution and now Having done that I'm going to upgrade these two projects because these have package references To that package. I'm going to upgrade those and I've just configured it to look in that directory So the upgrades go on ahead. That's all good. I'm now just going to rebuild everything here And we'll see how Now that we've got that PDB inside the package We'll see what the experience is of a developer trying to sort of use a run a program and debug a program That's using that package so Here we go So there is a problem it is going to throw an exception. That's expected However, if we look down here, and I'll sort of zoom in a bit for that There is it doesn't it doesn't know what the language was and it doesn't have the line number. So where is that? What's going on? Well, it turns out that there is this little bit of an issue with Dotnet framework projects that have portable PDB's in a new get package It's not copying the PDB from the new get package output to the Program output so then it doesn't find a PDB. So how can we solve that? If we have a look at this other project here, we can solve that by adding another package reference. So So people have figured out that There's some extra build steps we can add in that will will do that copying so if we add the reference to this new get package source link dot copy dot PDB files and We debug this one. So the only difference is adding including that extra Package reference, which is changes our build process If we debug this we'll still get the exception, but we do get the line numbers. So At least we know what line that exception was being thrown on so that's a bit better experience So so that's all good Okay, so our developers are happy with that The other thing we could do I stopped debugging this is even add Support for source link. So what that will do is Allow consumers of our package to actually step into the source code for the assembly that they're debugging from our package So I've already unloaded the the class library that we were using here So rather than trying to bring that back, let's just imagine that this project was also being packed in a new get package So all we need to do to make this Include information for source link is add in one extra line here and that is another package reference and So depending on what kind of source control you're using so or what source control provider There's different packages to help out with this. So in this case if I was using VSTS or as it's now known as your DevOps With git I could use that one or if I was using github. I would use that package and What it does is by including this package it updates the PDB to include some extra data That the debugger can then read and know where the source code is for this particular package So what does that look like? Well, let's see an example. I'll jump over and bring up a Project so what I've got here is an ASP net core web application and I didn't want to do that and The nice thing about all the latest ASP net core Projects is that they all they bring in all their functionality through new get packages that support source link So if I press F9 there to set a breakpoint, I'm gonna hit F5 to launch our application under the debugger and So there goes our web page and we've got our breakpoint here. And so then if I've got all the Everything set up correctly. I can press F11 To step into and now I'm stepping into the source code for ASP net core And so you can see there the path of that file is some path somewhere on my computer It's it's already been downloaded the first time you do this It will take a little while to go and download those files. I've already done that before so it was pretty quick the second time around But I can step through I can press F10 or F11 and step over and step into and jump through all that code So if I'm trying to debug a problem and I don't understand what's happening But behind the wrappers then I can can use that source link to step into the original source code so that's pretty cool experience and Just press F5 to finish that Cool Yes Yes Well, I can I can do I Can do better than that. I Well don't panic Yeah, no, it's all good because that was my final demo and so just wrapping up So it's all good so yeah just wrapping up just to keep things on time So I just showed you the new product system and how we can really reduce the size of our projects and reduce the amount of change We need in those particularly with package references. We can centralize version numbers in directory build targets There's a little sort of differences in dealing with generated files and the output paths We can generate new get packages directly from our project files And include PDB's portable PDB's in our new get packages and even add source link and Yeah, give the consumers of our packages a really great experience So all the demos I've given today are up on github in a repo and that's it there And I would try to include links to further resources and also links to the original sources for a lot of those tips because Don't be under the impression that I'm that clever. I just know how to search for stuff So when I encounter problems often I found someone also already figured out the solution so Some good resources there And I'm done. So thanks for everyone for your attention. And yes, if there's any questions, I'm happy to take those Yeah, that's cool. Yeah. Yeah Bye