Building,packaging,deploying,and Administering applications and Types

Before we go into the chapters, let's discuss the steps necessary to build, package, and deploy your application and application types. In this chapter, I will focus on how to generate assemblies for the purpose of your application. In chapter three, "Sharing program collections and strong named assemblies," I'll cover the high-level concepts you need to know, including how to build and use assemblies containing types that will be shared by multiple applications. In these two chapters, I'll also discuss how an administrator can influence the execution of an application and its type.

Today, applications are made up of several types, typically created by you and Microsoft. In addition, there are many component vendors that create and sell types that other companies can use to reduce software project development time. If these types are developed in any CLR-targeted language, they can work seamlessly together; one type of language write can use another type as its base class and does not care what language the underlying type was developed in.

In this chapter, I will explain these types in order to deploy how to build and package to files. In the process, I'll take you through some of the issues that are addressed by the. NET Framework.

. NET Framework depoyment goals(. NET Framework deployment targets)

Over the years, Windows has gained a reputation for instability and complexity. There are many different factors that make this reputation worthy. First, all applications use Microsoft or another vendor's dynamic link library (DLLs). Because an application executes code from a variety of vendors, any piece of code from a developer cannot be 100% sure how someone else is using it. Even though there are a variety of potential problems with this type of interaction, in fact, these problems generally do not occur because the application is tested and debugged before deployment.

In any case, when a company decides to update its code and load new files, users often run into problems. These new files are assumed to be backwards compatible with the previous files, but who can be sure? In fact, when a carrier updates its code, it generally finds it impossible to re-test and debug all loaded applications to ensure an unwanted impact.

I believe that every person who reads this book has experienced the mutation of this problem: When installing a new application, you find that it destroys an already installed application in some way. This dilemma is well known as "DLL Hell". This type of instability leaves a brand of fear in the minds and brains of ordinary computer users. As a result, users have to carefully consider whether to install a new software on their machine. For my own part, I decided not to try to install the application out of fear, which could adversely affect the applications I relied on.

The second reason to make a contribution to the aforementioned Windows reputation is the complexity of the installation. Today, when most applications are installed, they affect all parts of the system. For example, install an application that causes files to be copied to different directories, update the registry, and install shortcuts on your desktop and Start menu/desktop. The problem is that the application is not separated into a single entity. You cannot easily backup the application because you have to copy the application's files and register the relevant parts. In addition, you cannot easily move applications from one machine to another machine. You must run the Setup program once, all files and the registry can be set correctly. In the end, you can't easily uninstall or remove applications without the annoying feeling that some parts of the application are still lurking on your machine.

The third reason is related to security. When the application is installed, it is accompanied by a variety of files, many of which are written by different companies. In addition, Web applications often have code (just like ActiveX controls) to download, and users don't even notice that the code is already installed on their machine. Today, this code can do anything, including deleting files or sending e-mails. Users are afraid that installing new applications is correct because they can cause potential damage. To make the user comfortable, security must be established in the system, and users can explicitly allow or disallow code developed by different companies to access their system resources.

The. NET Framework puts DLL-hell issues in a critical position, as you'll see in this chapter and chapter three. The. NET Framework has gone a long way in repairing the state of an application scattered across the user's hard drive. For example, unlike COM, a type does not need to be set in the registry. Unfortunately, the application still needs a shortcut link. As for security, the. NET framework contains a security model called Code Access security. Since Windows security is based on user identity, code access security allows the machine master to set permissions, thereby controlling what the downloaded component can do. A host application like Microsoft SQL Server only gives the code a small amount of authorization, whereas a local installation (self-hosted) application runs with all permissions. As you'll see, the. NET framework gives users control over what to install and what to run, in short, Windows has never done this to control their machines.

Building Types into amodule (type generation of one block)

In this scenario, I will show you how to convert your source files (containing different types) into a file that can be deployed. Let's start with a closer look at the simple application below.

 Public Sealed class program    {        publicstaticvoid Main (string[] args)        {            System.Console.WriteLine ("Hi");        }    }

This application defines a type, called program. This type has a separate, public, static method called Main. A type called System.Console.System.Console is implemented by Microsoft in main, and the intermediate language (IL) code for this type of method is implemented in the MSCorLib.dll file. So our application defines a type that also uses the type of another company.

To build this simple application, put the previous code in a source code file called, Program.cs, and execute the following command line:

Csc.exe/out:program.exe/t:exe/r:mscorlib.dll Program.cs

This command line tells the C # compiler to publish an executable file called Program.exe (/out:program.exe). This type of file produces a WIN32 console application (/t[arget]:exe).

When the C # compiler processes the source file, it sees that the code refers to the WriteLine method of the System.Console type. At this point, the compiler will determine where this type exists, it has a WriteLine method, and the parameter is passed to the method, and the parameters expected by the method are matched. Because this type is not defined in C #, to make the C # compiler happy, you must give it an assembly that enables it to resolve external type references. In the previously mentioned command line, I have included the/r[eference]:mscorelib.dll switch, which tells the compiler to look for an external type through an assembly defined by the MSCorLib.dll file.

MSCorLib.dll is a special file that contains all the core types: Byte,char,string,int32 and others. In fact, these types are so frequently used by the C # compiler to automatically reference the MSCorLib.dll assembly. In other words, the following command line (omitting the/R switch) is the same as the command line result above.

Csc.exe/out:program.exe/t:exe Program.cs

Also, because the/out:program.exe and/t:exe command-line switches also match the default selection of the C # compiler, the following command line gives the same result.

Csc.exe Program.cs

If, for some reason, you really don't want the C # compiler to reference the MSCorLib.dll assembly, you can use the/nostdlib switch. This switch is used by Microsoft when establishing the MSCorLib.dll assembly. For example, the following command line will produce an error when CSC.exe tries to compile the Program.cs file because the System.Console type is defined in MSCorLib.dll.

Csc.exe/out:program.exe/t:exe/nostdlib Program.cs

Now, let's look closer at the C # compiler-generated Program.exe file. What is this file actually? Well, first of all, it's a standard portable actuator (portable executable,pe) file. This means that a machine running 32-bit or 64-bit versions of Windows can load this file and use it to do something. Windows supports three types of applications. Set up a console user Interface,cui application, specify the/t:exe switch, create a graphical user interface (graphical user Interface,gui) application, specify the/t:winexe switch ; Create a Windows Store app that specifies the/t:appcontainerexe switch.

Response Files(response document)

I'll take a moment to talk about the response document before I shelve the discussion about the compiled switch. A response file is a text file that contains a collection of compiler command-line switches. When you execute CSC.exe, the compiler opens the response document and uses the detailed defined switches as the command line is passed to CSC.exe. You command the compiler to use the specified response file by specifying the name of the response file by adding the @ sign at the command line. For example, you have a response file called MYPROJECT.RSP that contains the following text.

/out:myproject.exe

/target:winexe

In order for CSC.exe to use these settings, you can use the following content to invoke.

Csc.exe @MyProjext. RSP CodeFile1.cs CodeFile2.cs

This tells the C # compiler what name to output the file and what target type to create. As you can see, it's convenient to respond to the document because you don't need to manually give the command-line arguments your wishes every time you compile your project.

The C # compiler supports multiple response documents. In addition to the document you explicitly specify on the command line, the compiler automatically looks in the csc.rsp document. When you run CSC.exe, it looks for the directory that contains the CSC.exe file to get a comprehensive csc.rsp file. The settings you need to apply to your project should all be placed in this file. The compiler collection and the settings used in these response documents. If you have conflicting settings in the local and full response document, local settings overload the settings in the full response file. Similarly, any settings that are explicitly passed in the command line are set from the local response file overload.

Building,packaging,deploying,and Administering applications and Types