Heads up! This blog post is actually a reading log. I'm spending 30 minutes every day (more or less) reading C# via CLR by Jeffrey Richter and taking notes as I read it. This is tracked as a series on DevTo so you can read all parts of the series in order.
C# via CLR Reading Log 5: Chapter 2-3
In the last reading log, I had just finished up reading the portion of Chapter 2 that discussed assemblies. As it turns out, the content on assemblies continues. After covering them for a conceptual perspective, the book walks through how assemblies can be loaded into a project in VS, how to edit the metadata of the assembly, and more.
I'll be honest with you, reader, I skimmed through that ish faster than a speeding bullet. I'm just not into books that cover tooling and how to configure things. I much prefer to learn that stuff on an as-needed basis. It lasts much longer in my brain that way.
So I skimmed through pages of text and different pieces of metadata and what they mean until I landed upon an interesting looking section: "Simple Application Deployment (Privately Deployed Assemblies)." Deployment? Practical and intriguing!
I found a few tidbits in this section rather interesting:
- When you uninstall an application downloaded from the Windows in Windows, the assemblies associated with that application aren't removed until all users on the machine have uninstalled the application. This makes sense -- but I wonder what the historical motivation for this was?
- Applications don't just have to be installed from the Windows store. They can come from a variety of installers. Instead, the nteract desktop app for windows ships an EXE and MSI file for installation on Windows machines.
- Installing an application and getting it to show in the users' desktop and context menus are not the same thing. Boy do I know this! I spent some time researching adding support for a "Create new notebook" context menu item in nteract and it, unfortunately, requires some extra work. To be fair, a similar amount of extra work is required to bring the same functionality to other operating systems.
I skimmed through some more technical details and arrived at Chapter 3, which promises to cover the topic of shared assemblies and strongly typed assemblies.
Shared assemblies, aka globally deployed assemblies, are assemblies that can be used by multiple applications or other assemblies. Shared assemblies are useful for deploying reusable code, such as SDKs and frameworks. Indeed, the .NET framework is a globally deployed assembly.
Sidenote: It feels really weird to use the term "deployed' in the context of assets that run on a single-user machine. To be fair, an assembly can very well run on a cloud machine but I've always thought the term deployment should be referred to...I dunno...web apps? I guess it's time to stretch the imagination.
The book continues by discussing the file versioning conundrum and managing incompatibilities between different versions of assemblies and applications that depend on them. The book makes an astute point with this regard. A lot of applications exploit bugs in the frameworks and libraries they depend on. Having worked on the nteract core SDK, I know this to be true. Everyone's definition of what a bug is is different.
This reference is an allusion to the next portion of the book, which promises to discuss how the CLR handles versioning to avoid the variety of problems that occur as a result of version incompatibilities.
So, there are two different kinds of assemblies that the CLR can process: strongly-named assemblies and weakly-named assemblies. Although, Jeffrey clarifies that the term "weakly-named assembly" is one of his own makings that doesn't exist in the .NET framework documentation. To me, that's an indicator that something serious is about to happen! lol
The book clarifies that weakly-named and strongly-named assemblies are structurally the same. However, strongly-named assemblies are signed with a public/private key pair owned by the publisher while weakly-named assemblies are not. The CLR applies a different set of policies to strongly-named assemblies than it does to weakly-named ones. It makes sense to me. Code assets that have been signed deserve special treatment at run time than those that have not.
Strongly-named assemblies are the only assemblies that can be deployed globally, meaning they can be shared by other assemblies and applications on the machine. Once again, this makes sense. You want a certain layer of rigor given to assemblies that affect other components.
Today's 30 minutes are up -- but the book is about to dive into some interesting content around the approaches that .NET takes for managing global assemblies. Stay tuned for the next reading log!
Top comments (0)