Using optional arguments, you can specify only a specific runtime to publish for (option – r) or a different output directory (option – o). After running this command on a Windows system you can find a win7-x64 folder with all the files needed on the target system. Be aware that with .NET Core the runtime is included; thus it doesn’t matter what runtime version is installed.
You can use C# to create console applications; with most samples in the first chapters of this book you’ll do that exact thing. For real programs, console applications are not used that often. You can use C# to create applications that use many of the technologies associated with .NET. This section gives you an overview of the different types of applications that you can write in C#.
Data Access
Before having a look at the application types themselves, let’s look at technologies that are used by all application types: access to data.
Files and directories can be accessed by using simple API calls; however, the simple API calls are not flexible enough for some scenarios. With the stream API you have a lot of flexibility, and the streams offer many more features such as encryption or compression. Readers and writers make using streams easier. All of the different options available here are covered in Chapter 23, “Files and Streams.” It’s also possible to serialize complete objects in XML or JSON format. Chapter 27, “XML and JSON,” discusses these options.
To read and write to databases, you can use ADO.NET directly (see Chapter 37, “ADO.NET”), or you can use an abstraction layer, the ADO.NET Entity Framework (Chapter 38, “Entity Framework Core”). Entity Framework offers a mapping of object hierarchies to the relations of a database.
The ADO.NET Entity Framework made it through several iterations. The different versions of the Entity Framework are worth discussing; this gives you good information about why NuGet packages are a good idea. You’ll also learn what parts of the Entity Framework shouldn’t be used going forward.
The following table describes the different versions of the Entity Framework and each version’s new features.
Let’s get into some details. Entity Framework was originally released as part of the .NET Framework classes that come preinstalled with the .NET Framework. Entity Framework 1 was part of the first service pack of .NET 3.5, which was a feature update: .NET 3.5 Update 1.
The second version had so many new features that the decision was made to move to version 4 together with .NET 4. After that, Entity Framework was released at a faster cadence than the .NET Framework. To get a newer version of Entity Framework, a NuGet package had to be added to the application (versions 4.1, 4.2, 4.3). There was a problem with this approach. Classes that have already been delivered with the .NET Framework had to be used as is. Just additional features, such as Code First, have been added with NuGet packages.
With .NET 4.5, Entity Framework 5.0 was released. Again some of the classes come with the preinstalled .NET Framework, and additional features are part of NuGet packages. The NuGet package also made it possible to allow installing the NuGet package for Entity Framework 5.0 with .NET 4.0 applications. However, in reality the package decided (via a script) in a case when Entity Framework 5.0 is added to a .NET 4.0 project that the result would be Entity Framework 4.4 because some of the types required belong to .NET 4.5 and are not part of .NET 4.
The next version of Entity Framework solved this problem by moving all the Entity Framework types to a NuGet package; the types that come with the Framework itself are ignored. This allows using version 6.0 with older versions of the Framework; you aren’t restricted to 4.5. To not conflict with classes of the Framework, some types moved to a different namespace. Some features of ASP.NET Web Forms had an issue with that because original classes of the Entity Framework have been used, and these do not map that easily to the new classes.
During the different releases, Entity Framework gives different options for mapping the database tables to classes. The first two options were Database First and Model First. With both of these options, the mapping was done via XML files. The XML file is presented via a graphical designer, and it’s possible to drag entities from the toolbox to the designer for doing the mapping.
With version 4.1, mapping via code was added: Code First. Code First doesn’t mean that the database can’t exist beforehand. Both are possible: A database can be created dynamically, but also the database can exist before you write the code. Using Code First, you don’t do the mapping via XML files. Instead, attributes or a fluent API can define the mapping programmatically.
Entity Framework Core 1.0 is a complete redesign of Entity Framework, as is reflected with the new name. Code needs to be changed to migrate applications from older versions of Entity Framework to the new version. Older mapping variants, such as Database First and Model First, have been dropped, as Code First is a better alternative. The complete redesign was also done to support not only relational databases but also NoSQL. Azure Table Storage is one of the options where Entity Framework can now be used.
Windows Desktop Applications
For creating Windows desktop applications, two technologies are available: Windows Forms and Windows Presentation Foundation. Windows Forms consists of classes that wrap native Windows controls; it’s based on pixel graphics. Windows Presentation Foundation (WPF) is the newer technology and is based on vector graphics.
WPF makes use of XAML in building applications. XAML stands for eXtensible Application Markup Language. This way to create applications within a Microsoft environment was introduced in 2006 and is part of the .NET Framework 3.0.NET 4.5 introduced new features to WPF, such as ribbon controls and live shaping.
XAML is the XML declaration used to create a form that represents all the visual aspects and behaviors of the WPF application. Though you can work with a WPF application programmatically, WPF is a step in the direction of declarative programming, which the industry is moving to. Declarative programming means that instead of creating objects through programming in a compiled language such as C#, Visual Basic, or Java, you declare everything through XML-type programming. Chapter 29, “Core XAML,” introduces XAML (which is also used with XML Paper Specification, Windows Workflow Foundation, and Windows Communication Foundation). Chapter 30 covers XAML styles and resources. Chapter 34, “Windows Desktop Applications with WPF,” gives details on controls, layout, and data binding. Printing and creating documents is another important aspect of WPF that’s covered in Chapter 35, “Creating Documents with WPF.”
What’s the future of WPF? Isn’t the UWP the UI platform to use for new applications going forward? UWP has advantages in supporting mobile devices as well. As long as some of your users have not upgraded to Windows 10, you need to support older operating systems such as Windows 7. UWP apps don’t run on Windows 7 or Windows 8. You can use WPF. In case you also would like to support mobile devices, it’s best to do as much code sharing as possible. You can create apps with both WPF and UWP by using as much common code as possible by supporting the MVVM pattern. This pattern is covered in Chapter 31, “Patterns with XAML Apps.”
Universal Windows Platform
The Universal Windows Platform (UWP) is a strategic platform from Microsoft. When you use the UWP to create Windows apps, you’re limited to Windows 10 and newer versions of Windows. But you’re not bound to the desktop version of Windows. With Windows 10 you have a lot of different options, such as Phone, Xbox, Surface Hub, HoloLens, and IoT. There’s one API that works on all these devices!
One API for all these devices? Yes! Each device family can add its own Software Development Kit (SDK) to add features that are not part of the API that’s available for all devices. Adding these SDKs does not break the application, but you need to programmatically check whether an API from such an SDK is available on the platform the app is running. Depending on how many API calls you need to differentiate, the code might grow into a mess; dependency injection might be a better option.
NOTE