Say my name: The Evolution of Shared Libraries

Say my name: The Evolution of Shared Libraries

by | Jan 21, 2025 | Uncategorized

During my recent AI research break, I found myself taking a walk down memory lane, reflecting on my early career in data analysis and ETL operations. This journey brought me back to an interesting aspect of software development that has evolved significantly over the years: the management of shared libraries.

The VB6 Era: COM Components and DLL Hell

My journey began with Visual Basic 6, where shared libraries were managed through COM components. The concept seemed straightforward: store shared DLLs in the Windows System directory (typically C:\Windows\System32) and register them using regsvr32.exe. The Windows Registry kept track of these components under HKEY_CLASSES_ROOT.

However, this system had a significant flaw that we now famously know as “DLL Hell.” Let me share a practical example: Imagine you have two systems, A and B, both using Crystal Reports 7. If you uninstall either system, the other would break because the shared DLL would be removed. Version control was primarily managed by location, making it a precarious system at best.

Enter .NET Framework: The GAC Revolution

When Microsoft introduced the .NET Framework, it brought a sophisticated solution to these problems: the Global Assembly Cache (GAC). Located at C:\Windows\Microsoft.NET\assembly\ (for .NET 4.0 and later), the GAC represented a significant improvement in shared library management.

The most revolutionary aspect was the introduction of assembly identity. Instead of relying solely on filenames and locations, each assembly now had a unique identity consisting of:

  • Simple name (e.g., “MyCompany.MyLibrary”)
  • Version number (e.g., “1.0.0.0”)
  • Culture information
  • Public key token

A typical assembly full name would look like this:

MyCompany.MyLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

This robust identification system meant that multiple versions of the same assembly could coexist peacefully, solving many of the versioning nightmares that plagued the VB6 era.

The Modern Approach: Private Dependencies

Fast forward to 2025, and we’re living in what I call the “brave new world” of .NET for multi-operative systems. The landscape has changed dramatically. Storage is no longer the premium resource it once was, and the trend has shifted away from shared libraries toward application-local deployment.

Modern applications often ship with their own private version of the .NET runtime and dependencies. This approach eliminates the risks associated with shared components and gives applications complete control over their runtime environment.

Reflection on Technology Evolution

While researching Blazor’s future and seeing discussions about Microsoft’s technology choices, I’m reminded that technology evolution is a constant journey. Organizations move slowly in production environments, and that’s often for good reason. The shift from COM components to GAC to private dependencies wasn’t just a technical evolution – it was a response to real-world problems and changing resources.

This journey from VB6 to modern .NET reveals an interesting pattern: sometimes the best solution isn’t sharing resources but giving each application its own isolated environment. It’s fascinating how the decreasing cost of storage and increasing need for reliability has transformed our approach to dependency management.

As I return to my AI research, this trip down memory lane serves as a reminder that while technology constantly evolves, understanding its history helps us appreciate the solutions we have today and better prepare for the challenges of tomorrow.

Happy coding!
Understanding XtraReports: A Windows Forms Developer’s Guide

Understanding XtraReports: A Windows Forms Developer’s Guide

by | Jan 2, 2025 | XtraReports

Introduction 🎯

If you’re familiar with Windows Forms development, transitioning to XtraReports will feel remarkably natural. This guide explores how XtraReports leverages familiar Windows Forms concepts while extending them for robust reporting capabilities.

💡 Quick Tip: Think of XtraReports as Windows Forms optimized for paper output instead of screen output!

A Personal Journey ✨

Microsoft released .NET Framework in late 2002. At the time, I was a VB6 developer, relying on Crystal Reports 7 for reporting. By 2003, my team was debating whether to transition to this new thing called .NET. We were concerned about VB6’s longevity—thinking it had just a couple more years left. How wrong we were! Even today, VB6 applications are still running in some places (it’s January 2, 2025, as I write this).

Back in the VB6 era, we used the Crystal Reports COM object to integrate reports. When we finally moved to .NET Framework, we performed some “black magic” to continue using our existing 700 reports across nine countries. The decision to fully embrace .NET was repeatedly delayed due to the sheer volume of reports we had to manage. Our ultimate goal was to unify our reporting and parameter forms within a single development environment.

This led us to explore other technologies. While considering Delphi, we discovered DevExpress. My boss procured our first DevExpress .NET license for Windows Forms, marking the start of my adventure with DevExpress and XtraReports. Initially, transitioning from the standalone Crystal Report Designer to the IDE-based XtraReports Designer was challenging. To better understand how XtraReports worked, I decided to write reports programmatically instead of using the visual designer.

Architectural Similarities 🗽️

XtraReports mirrors many fundamental Windows Forms concepts:

Source Destination
XtraReport Class Report Designer Surface
XtraReport Class Control Container
XtraReport Class Event System
XtraReport Class Properties Window
Control Container Labels & Text
Control Container Tables & Grids
Control Container Images & Charts
Report Designer Surface Control Toolbox
Report Designer Surface Design Surface
Report Designer Surface Preview Window

Like how Windows Forms applications start with a Form class, XtraReports begin with an XtraReport base class. Both serve as containers that can:

  • Host other controls
  • Manage layout
  • Handle events
  • Support data binding

Visual Designer Experience 🎨

The design experience remains consistent with Windows Forms:

Windows Forms XtraReports
Form Designer Report Designer
Toolbox Report Controls
Properties Window Properties Grid
Component Tray Component Tool

Control Ecosystem 🧰

XtraReports provides analogous controls to Windows Forms:


// Windows Forms
public partial class CustomerForm : Form
{
    private Label customerNameLabel;
    private DataGridView orderDetailsGrid;
}

// XtraReports
public partial class CustomerReport : XtraReport
{
    private XRLabel customerNameLabel;
    private XRTable orderDetailsTable;
}

Common control mappings:

  • Label ➡️ XRLabel
  • Panel ➡️ XRPanel
  • PictureBox ➡️ XRPictureBox
  • DataGridView ➡️ XRTable
  • GroupBox ➡️ Band
  • UserControl ➡️ Subreport

Data Binding Patterns 📊

The data binding syntax maintains familiarity:


// Windows Forms data binding
customerNameLabel.DataBindings.Add("Text", customerDataSet, "Customers.Name");

// XtraReports data binding
customerNameLabel.ExpressionBindings.Add(
    new ExpressionBinding("Text", "[Name]"));

Code Architecture 🗍️

The code-behind model remains consistent:


public partial class CustomerReport : DevExpress.XtraReports.UI.XtraReport
{
    public CustomerReport()
    {
        InitializeComponent(); // Familiar Windows Forms pattern
    }

    private void CustomerReport_BeforePrint(object sender, PrintEventArgs e)
    {
        // Event handling similar to Windows Forms
        // Instead of Form_Load, we have Report_BeforePrint
    }
}

Key Differences ⚡

While similarities abound, important differences exist:

  1. Output Focus 🖨️
    • Windows Forms: Screen-based interaction
    • XtraReports: Print/export optimization
  2. Layout Model 📜
    • Windows Forms: Flexible screen layouts
    • XtraReports: Page-based layouts with bands
  3. Control Behavior 🎮
    • Windows Forms: Interactive controls
    • XtraReports: Display-oriented controls
  4. Data Processing 🗄️
    • Windows Forms: Real-time data interaction
    • XtraReports: Batch data processing

Some Advices 🌟

  1. Design Philosophy 
    
// Think in terms of paper output
public class InvoiceReport : XtraReport
{
    protected override void OnBeforePrint(PrintEventArgs e)
    {
        // Calculate page breaks
        // Optimize for printing
    }
}
  2. Layout Strategy
    • Use bands for logical grouping
    • Consider paper size constraints
    • Plan for different export formats
  3. Data Handling
    • Pre-process data when possible
    • Use calculated fields for complex logic
    • Consider subreports for complex layouts
Getting Started with Stratis Blockchain Development Quest: Running Your First Stratis Node

Getting Started with Stratis Blockchain Development Quest: Running Your First Stratis Node

by | Jun 11, 2024 | Uncategorized

Getting Started with Stratis Blockchain Development: Running Your First Stratis Node

Stratis is a powerful and flexible blockchain development platform designed to enable businesses and developers to build, test, and deploy blockchain applications with ease. If you’re looking to start developing for the Stratis blockchain, the first crucial step is to run a Stratis node. This article will guide you through the process, providing a clear and concise roadmap to get your development journey underway.

Introduction to Stratis Blockchain

Stratis offers a blockchain-as-a-service (BaaS) platform, which simplifies the development, deployment, and maintenance of blockchain solutions. Built on a foundation of the C# programming language and the .NET framework, Stratis provides an accessible environment for developers familiar with these technologies. Key features of Stratis include smart contracts, sidechains, and full node capabilities, all designed to streamline blockchain development and integration.

Why Run a Stratis Node?

Running a Stratis node is essential for several reasons:

  • Network Participation: Nodes form the backbone of the blockchain network, validating and relaying transactions.
  • Development and Testing: A local node provides a controlled environment for testing and debugging blockchain applications.
  • Decentralization: By running a node, you contribute to the decentralization and security of the Stratis network.

Prerequisites

Before setting up a Stratis node, ensure you have the following:

  • A computer with a modern operating system (Windows, macOS, or Linux).
  • .NET Core SDK installed.
  • Sufficient disk space (at least 10 GB) for the blockchain data.
  • A stable internet connection.

Step-by-Step Guide to Running a Stratis Node

1. Install .NET Core SDK

First, install the .NET Core SDK, which is necessary to run the Stratis Full Node. You can download it from the official .NET Core website. Follow the installation instructions for your specific operating system. I recommend having all DotNetCore SDKs because the source code for most of the Stratis solutions target really an old framework version like.NET Core 2.1 so it’s better to have multiple choices of framework in case you need to re-target for compatibility

.NET Core Versions

  • .NET Core 3.1 (LTS)
  • .NET Core 3.0
  • .NET Core 2.2
  • .NET Core 2.1 (LTS)
  • .NET Core 2.0
  • .NET Core 1.1
  • .NET Core 1.0

Installation Links

Download .NET Core SDKs

2. Clone the Stratis Full Node Repository

Next, clone the Stratis Full Node repository from GitHub. Open a terminal or command prompt and run the following command:

git clone https://github.com/stratisproject/StratisFullNode.git

This command will download the latest version of the Stratis Full Node source code to your local machine.

3. Build the Stratis Full Node

Navigate to the directory where you cloned the repository:

cd StratisFullNode

Now, build the Stratis Full Node using the .NET Core SDK:

dotnet build

This command compiles the source code and prepares it for execution.

4. Run the Stratis Full Node

Once the build process is complete, you can start the Stratis Full Node. Use the following command to run the node:

cd Stratis.StraxD
dotnet run -testnet

This will initiate the Stratis node, which will start synchronizing with the Stratis blockchain network.

5. Verify Node Synchronization

After starting the node, you need to ensure it is synchronizing correctly with the network. You can check the node’s status by visiting the Stratis Full Node’s API endpoint in your web browser:

http://localhost:37221/api

here is more information about the possible ports for the API depending on which network you want to use (test or main) and which command did you use to start up the API

Swagger
To run the API in a specific port you can use the following code

StraxTest (dotnet run -testnet -apiport=38221)

http://localhost:38221/Swagger/index.html

StraxTest

http://localhost:27103/Swagger

StraxMain

http://localhost:17103/Swagger

You should see a JSON response indicating the node’s current status, including its synchronization progress.

Conclusion

Congratulations! You have successfully set up and run your first Stratis node. This node forms the foundation for your development activities on the Stratis blockchain. With your node up and running, you can now explore the various features and capabilities of the Stratis platform, including deploying smart contracts, interacting with sidechains, and building blockchain applications.

As you continue your journey, remember that the Stratis community and its comprehensive documentation are valuable resources. Engage with other developers, seek guidance, and contribute to the growing ecosystem of Stratis-based solutions. Happy coding!

 

Previous articles

Discovering the Simplicity of C# in Blockchain Development with Stratis | Joche Ojeda

 

A Beginner’s Guide to System.Security.SecurityRules and SecuritySafeCritical in C#

A Beginner’s Guide to System.Security.SecurityRules and SecuritySafeCritical in C#

by | Apr 24, 2024 | C#, netframework

 

A Beginner’s Guide to System.Security.SecurityRules and SecuritySafeCritical in C#

Introduction

In the .NET Framework, security is a critical concern. Two attributes, System.Security.SecurityRules and SecuritySafeCritical, play a significant role in enforcing Code Access Security (CAS).

System.Security.SecurityRules

The System.Security.SecurityRules attribute specifies the set of security rules that the common language runtime should enforce for an assembly. It has two levels: Level1 and Level2.

Level1

Level1 uses the .NET Framework version 2.0 transparency rules. Here are the key rules for Level1:

  • Public security-critical types and members are treated as security-safe-critical outside the assembly.
  • Security-critical types and members must perform a link demand for full trust to enforce security-critical behavior when they are accessed by external callers.
  • Level1 rules should be used only for compatibility, such as for .NET Framework 2.0 assemblies.

[assembly: System.Security.SecurityRules(System.Security.SecurityRuleSet.Level1)]
public class MyClass
{
    // Your code here
}

SecuritySafeCritical

The SecuritySafeCritical attribute identifies types or members as security-critical and safely accessible by transparent code. Code marked with SecuritySafeCritical must undergo a rigorous security audit to ensure that it can be used safely in a secure execution environment. It must validate the permissions of callers to determine whether they have authority to access protected resources used by the code.


[System.Security.SecuritySafeCritical]
public void MyMethod()
{
    // Your code here
}

Relationship between System.Security.SecurityRules and SecuritySafeCritical

The System.Security.SecurityRules and SecuritySafeCritical attributes work together to enforce security in .NET Framework. An assembly marked with SecurityRules(SecurityRuleSet.Level1) uses the .NET Framework version 2.0 transparency rules, where public security-critical types and members are treated as security-safe-critical outside the assembly.

The concept of trusted Code

Trusted code refers to code that has been granted certain permissions and is considered safe to execute. It’s a combination of techniques, policies, and procedures for which there is no plausible scenario in which a document retrieved from or reproduced by the system could differ substantially from the document that is originally stored. In other words, trusted code certifies that electronically stored information (ESI) is an authentic copy of the original document or information.

Use Cases and Examples

Consider a scenario where you have a method that performs a critical operation, such as accessing a protected resource. You want to ensure that this method can only be called by trusted code. You can mark this method as SecuritySafeCritical to enforce this.


[System.Security.SecuritySafeCritical]
public void AccessProtectedResource()
{
    // Code to access protected resource
}

In this case, the AccessProtectedResource method can only be called by code that has been granted the necessary permissions. This helps to prevent unauthorized access to the protected resource.

Conclusion

Understanding the System.Security.SecurityRules and SecuritySafeCritical attributes is crucial when developing secure .NET applications. By using these attributes correctly, you can enforce robust security rules and protect your application from potential threats. Always remember, with great power comes great responsibility!

I hope this article helps you understand these concepts better. Happy coding! 😊

 

Understanding AppDomains in .NET Framework and .NET 5 to 8

Understanding AppDomains in .NET Framework and .NET 5 to 8

by | Mar 7, 2024 | C#, dotnet, netcore, netframework

Understanding AppDomains in .NET Framework and .NET 5 to 8

AppDomains, or Application Domains, have been a fundamental part of isolation and security in the .NET Framework, allowing multiple applications to run under a single process without affecting each other. However, the introduction of .NET Core and its evolution through .NET 5 to 8 has brought significant changes to how isolation and application boundaries are handled. This article will explore the concept of AppDomains in the .NET Framework, their transition and replacement in .NET 5 to 8, and provide code examples to illustrate these differences.

AppDomains in .NET Framework

In the .NET Framework, AppDomains served as an isolation boundary for applications, providing a secure and stable environment for code execution. They enabled developers to load and unload assemblies without affecting the entire application, facilitating application updates, and minimizing downtime.

Creating an AppDomain

using System;

namespace NetFrameworkAppDomains
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create a new application domain
            AppDomain newDomain = AppDomain.CreateDomain("NewAppDomain");

            // Load an assembly into the application domain
            newDomain.ExecuteAssembly("MyAssembly.exe");

            // Unload the application domain
            AppDomain.Unload(newDomain);
        }
    }
}

AppDomains in .NET 5 to 8

With the shift to .NET Core and its successors, the concept of AppDomains was deprecated, reflecting the platform’s move towards cross-platform compatibility and microservices architecture. Instead of AppDomains, .NET 5 to 8 emphasizes on assembly loading contexts for isolation and the use of containers (like Docker) for application separation.

AssemblyLoadContext in .NET 5 to 8

using System;
using System.Reflection;
using System.Runtime.Loader;

namespace NetCoreAssemblyLoading
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create a new AssemblyLoadContext
            var loadContext = new AssemblyLoadContext("MyLoadContext", true);

            // Load an assembly into the context
            Assembly assembly = loadContext.LoadFromAssemblyPath("MyAssembly.dll");

            // Execute a method from the assembly (example method)
            MethodInfo methodInfo = assembly.GetType("MyNamespace.MyClass").GetMethod("MyMethod");
            methodInfo.Invoke(null, null);

            // Unload the AssemblyLoadContext
            loadContext.Unload();
        }
    }
}

Differences and Considerations

  • Isolation Level: AppDomains provided process-level isolation without needing multiple processes. In contrast, AssemblyLoadContext provides a lighter-weight mechanism for loading assemblies but doesn’t offer the same isolation level. For higher isolation, .NET 5 to 8 applications are encouraged to use containers or separate processes.
  • Compatibility: AppDomains are specific to the .NET Framework and are not supported in .NET Core and its successors. Applications migrating to .NET 5 to 8 need to adapt their architecture to use AssemblyLoadContext or explore alternative isolation mechanisms like containers.
  • Performance: The move away from AppDomains to more granular assembly loading and containers reflects a shift towards microservices and cloud-native applications, where performance, scalability, and cross-platform compatibility are prioritized.

Conclusion

While the transition from AppDomains to AssemblyLoadContext and container-based isolation marks a significant shift in application architecture, it aligns with the modern development practices and requirements of .NET applications. Understanding these differences is crucial for developers migrating from the .NET Framework to .NET 5 to