Autor: Michael

Fragen die in diesen Artikel beantwortet werden:

• Wie kann ich automatisch (on build) nuget-Packages erstellen?
• Wie kann ich Parameter an den nuget build Task übergeben?
• Wie kann ich code duplizierung vermeiden?
• Wie kann ich weitere Dateien in mein nuget packages einfügen?
• Was muss ich tun um SourceLink in den nuget packages zu aktivieren?

Visual Studio 2019 hat für die Erstellung der NuGet Packages eine eingebaute Möglichkeit NuGet-Pakete zu erstellen. Die Möglichkeit wurde nicht mit den ersten Versionen des Visual Studios  bereitgestellt und ist zum aktuellen Zeitpunkt (anfang 2021) nicht voll umfänglich verfübar. Es gibt keine Möglichkeit, je nach Configuration (Debug/Release) unterschiedliche packages oder dependencies hinzuzufügen. Ebenso können keine Build-Dateien und Targets hinzugefügt werden. Aus diesen Grund wird hier die realisierung mit einer „nuspec“-Datei betrachtet.

Um die wiederverwendung zu vereinfachen, wurde innerhalb der benötigten Projekte in Visual Studio ein include verwendet, welches via <Import Project=“..\Default.csproj“ /> im project hinzugefügt werden.

Hier ein Beispiel einer csproj-Datei eines Projektes:

<Project Sdk="Microsoft.NET.Sdk">
    <!-- Modify properties for project here -->
    <PropertyGroup>
        <!-- You can modify your nuget package name here. -->
        <PackageId>$(MSBuildProjectName)</PackageId>
        <!-- If not added here, is default 1.0.0 is used. -->
        <Version>1.0.2</Version>
    </PropertyGroup>
       <!-- Include default project -->
    <Import Project="..\default.csproj" />
    <ItemGroup>
        <!-- Add package references. -->
    </ItemGroup>
    <ItemGroup>
        <!-- Add project references. -->
    </ItemGroup>
</Project>

Hier der Inhalt der default.csproj

<Project DefaultTargets="Build"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <!-- Change or update values in this Property group -->
    <PropertyGroup>
        <Authors></Authors>
        <Company></Company>
        <RepositoryUrl></RepositoryUrl>
        <!-- E.g. git -->
        <RepositoryType></RepositoryType>
        <Description></Description>
        <!-- If you want to publish on *every* build change this to true, consider that nuget packages needs to be unique and once published they should not be changed. This might make sense on the CI-System. -->
        <PublishRepositoryUrl>false</PublishRepositoryUrl>
    </PropertyGroup>
    <PropertyGroup>
<Deterministic>true</Deterministic>
        <IncludeSymbols>true</IncludeSymbols>
        <SymbolPackageFormat>snupkg</SymbolPackageFormat>
        <EmbedUntrackedSources>true</EmbedUntrackedSources>
        <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
        <OutputPath>bin\$(Configuration)</OutputPath>
        <DocumentationFile>bin\$(Configuration)\$(MSBuildProjectName).xml</DocumentationFile>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <Nullable>enable</Nullable>
        <GeneratePackageOnBuild>false</GeneratePackageOnBuild>
    </PropertyGroup>
    <ItemGroup Label="NugetAndDefaults">
        <PackageReference Include="Microsoft.SourceLink.AzureDevOpsServer.Git" Version="1.0.0">
            <PrivateAssets>all</PrivateAssets>
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        </PackageReference>        <!-- Add your Server variables: $(GitServerDomain) and $(GitServerPath) -->
        <SourceLinkAzureDevOpsServerGitHost Include="$(GitServerDomain)" VirtualDirectory="$(GitServerPath)" />
    </ItemGroup>
    <Target Name="PostBuild" AfterTargets="PostBuildEvent">
        <Exec Command="..\Nuget\nuget.exe pack ..\Nuget\$(PackageId).nuspec -Properties Version=$(Version);Id=$(PackageId);Title=$(PackageId);ProjectName=$(MSBuildProjectName);Configuration=$(Configuration) -Output bin\$(Configuration) " />
    </Target>
</Project>

Nun wird beim Build des Projectes eine nuspec-Datei benötigt: $(PackageId).nuspec

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>$id$</id>
        <title>$title$</title>
        <version>$version$</version>
        <!-- Add the authors -->
        <authors></authors>
        <!-- Add the owners -->
        <owners></owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <developmentDependency>false</developmentDependency>
        <!-- Add the description -->
        <description></description>
        <!-- All you required package dependencies -->
        <dependencies></dependencies>
    </metadata>
    <files>
        <file src="..\README.md" target="README.md" />
        <file src="..\$ProjectName$\bin\$configuration$\netcoreapp3.1\$ProjectName$.dll" target="lib\netcoreapp3.1\$ProjectName$.dll" />
        <file src="..\$ProjectName$\bin\$configuration$\netcoreapp3.1\$ProjectName$.pdb" target="lib\netcoreapp3.1\$ProjectName$.pdb" />
        <file src="..\$ProjectName$\bin\$configuration$\$ProjectName$.xml" target="Build\$ProjectName$.xml" />
        <file src="$id$.targets" target="Build\$id$.targets" />
    </files>
</package>

In this example, there is an additional file added for the xml documentation file, which later linked in the target project. This is done in a Build-Target within the nuget package, this file must be named $(PackageId).targets:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <!-- Replace Contoso.xml with the documentation file needed. -->
        <None Include="$(MSBuildThisFileDirectory)\Contoso.xml">
            <Link>Contoso.xml</Link>            <CopyToOutputDirectory>Always</CopyToOutputDirectory>
        </None>
    </ItemGroup>
</Project>

Folgende inhalte folgen hier noch:

• git links
• t4 um das  nuspec file zu erstellen.
• Lösung als nuget package
• Eigene GUI um packages zu erzeugen

Mit der Gründung am 18.05.2020 und der finalen Eintragung ins Handelsregister ist Minicon nun eine eingetragene Genossenschaft (eG).

Die Gründungsmitglieder sind:

• Daniel Ivanovic
• Andrey Mir
• Michael Nikolaus (Vorstand)

 

I’ve re-read this book after 10 Years to challenge my self, how and what I’m doing. This time I read the german edition, which in general I do not recommend when reading it the first time.

First of all I have to say that, after working several years in the IT Industry,  the hard thing about creating Software isn’t the Software itself. 

There are the processes behind it which makes the Projects fails, and there mainly the missing Analysis and Processes. At least with a clean architecture you can compensate that. But, shit in shit out, will be in the most cases the excuse for the Architects if the Software failed. And, most times, they are right.

As a summary I can point out the most important things:

• SOLID Principals are fundamental, but 80% of developers do not completely understand them.
• Architecture is about building walls between diffent layers.
• If you want to build a good architecture, you need to understand deeply how Code gets coupled and how to uncouple it.
• This Book show you were those walls should be.

Since Uncle Bob is a Storyteller, this Book could be much more light-weighted. But at least, good to read amnd to understand the SOLID Principles. I can not recommend to read through the Part 6, which is about details and everything after it. It’s just timeconsuming and gives you a kind of „Confirmation“ which doesn’t bring you forwad.

Hope this short POST prepared you to read, or not to read the Book. If you check for Uncle Bob’s Youtube video, at least it’s more entertaining and focused. 

• SOLID Principles
• Principles of clean clean architecture
• Future of Code

Clean Architecture @ Amazon

I just heard a good Statement about Object-Oriented Programming and Functional Programming. I‘m not against FP but I decided to use the OOP approach. Trying to be best at it.

OOP and FP are tools.
…
It doesn’t matter what programming paradigm you use. The problems presented in most of the articles are about organizing your code.
To me the macrostructure of the application matters a lot more: what are the modules? How do they communicate with each other? What are the common data structures? How are these documented? What are the important business objects?

These are all questions that have nothing to do with the programming paradigm in use, and the programming paradigm doesn’t even solve. A good programmer will learn the paradigm as a matter of knowing one’s tool and will use whichever is appropriate for the given task.
…

So I totally agree with that statement, and if it is hard to understand the paradigms behind the code I write. I‘ll create several Blogposts with Examples and the Pro/Cons behind it.

In general, as you will see, I don‘t Invent something new, at least I try to use the best approach for the Product. And the best thing for a product is, that is easy to maintained and to be evolved.

As a Software Architect, I have my main focused shift to the general concepts and pattern used. Always focused on Stability and Maintainability.

There are many patterns and concepts out there to support a better Maintainability, but many of them are not used by developers and I always have to explain them again and again. So, the following text will shortly explain which I use in my code.

Naming classes and methods

As started years ago with Clean code, we should name our Methods as descriptive as possible right? But, this also has its downsides, so I’ve started the Builders and Manipulators approach. Since the reasoning behind that naming schema is strongly tight of my understanding of how classes should behave. Mainly because, when using an object, I’m not interested in how it services my request. I’m just interested in what I receive, which is much more declarative instead of imperative.

Declarative programming is a programming paradigm … that expresses the logic of a computation without describing its control flow.

Imperative programming is a programming paradigm that uses statements that change a program’s state.

https://codeburst.io/declarative-vs-imperative-programming-a8a7c93d9ad2

So, how I determine the names of classes, methods, and functions?

• A class instance is a representation of the parameters given to the constructor. This representation has a behavior described by its interfaces and its name.
• Functions results are a representation of its parameters a the result and its name.
• Methods describe its changes with its name and parameters.

class Point
{
   // Represents a Point in a defined color.
   public Point(color)
   : this(color, x, y) 
   ...

   // Represents a Point in a defined color.
   public Point(color, x, y)
   ...
   
   public String String() => _color;
   // Represents a Line with the given end point. 
   // Since this is scoped to the current Class its clear,
   // that this line ist from its starting point.
   public Line Line(Point endpoint) 
   ...
   
   // Change its x,y coordinated to the given destination.
   // -> In general, I do not recommend to use Modifiers,
   // since they are creating mutable objects. But for 
   // demonstrating this is fine.
   public Move(Point destination)
}

This Article is in progress, feed free to give Feedback before it is finished.

• Wird Tesla die Autoindustrie dominieren?
• Wird Apple noch relevant sein?
• Werden Microservices gegen Lambda functions und co verlieren?
• Wird es ein InternetOS geben? Ein Netzwerk welches Daten, Berechnungen automatisch verteilt und man wird noch Streaming Clients benötigen?
• AI Standard sein? Wird AI code schreiben und wir nur noch Definitionen?
• Werden Autos, Drohnen und Lkws Autonom sein? 

 

Ich glaube es ist nur eine Frage der Zeit, schauen wir in zehn Jahren nochmal.