Private Assembly Deployment

for RuBoard

For private assembly deployment, the assembly is copied to the same directory as the client program that references it. No registration is needed, and no fancy installation program is required. When the component is removed, no registry cleanup is needed, and no uninstall program is required. Just delete it from the hard drive. ^[7]

^[7] Of course this process does not put any icons on the desktop or entries on the Start menu.

Of course, no self-respecting programmer would ever provide a commercial component that required the end user to manually copy or delete any files in this way, even if it is remarkably simple to do. Users have become accustomed to using a formal installation program, so it should be provided, even if its work is trivial. However, for testing purposes, manually copying and deleting an assembly is an ideal way to quickly and painlessly manage deployment issues for developing, debugging, or testing purposes. Recall that the deployment of COM components was never this simple, requiring at a minimum, a registry script file. Gone are the days where you have to configure the registry on installation, and then later carefully clean out the registry information when you want to discard the component.

To privately deploy our componentized Hotel Administrator case study, create a directory on your hard drive. Copy to that directory the files in the CaseStudy\bin\Debug directory, AcmeGui.exe , Customer.dll , and Hotel.dll . Then run AcmeGui.exe . It will run. It is really just that simple!

If you view the AcmeGui manifest in ILDASM , you will see the following dependency entries:

 .assembly extern Customer    {    .ver 1:0:593:19533  }  .assembly extern Hotel  {    .ver 1:0:593:19532  } 

Here are the corresponding assembly definitions in the components:

 .assembly Customer  {    ...    .hash algorithm 0x00008004    .ver 1:0:593:19533   }  .assembly Hotel  {    ...    .hash algorithm 0x00008004    .ver 1:0:593:19532  } 

From this you can see that the client program was built with Customer assembly version 1.0.593.19533 and Hotel assembly version 1.0.593.19532. Since neither assembly has a strong name , however, the versions are not checked. If you were to build a Customer assembly with a different version, and replace the one that AcmeGui was built with, AcmeGui would still run. It does not matter whether you change the major build number or the revision number.

If you were to use a version of the Customer component with a strong name (even if it had the same version number), you would get the following runtime exception:

 System.IO.FileLoadException: The located assembly's mani fest definition with name 'Customer' does not match the  assembly reference. 

If the Customer assembly has a strong name, even if the version numbers are the same, the assembly names no longer match. If the AcmeGui client program was built with an assembly that had a strong name, the CLR will bind only to an assembly that matches exactly with the strong name and version. Even a different revision number will cause the load to fail.

The details on binding failures can be seen in the Assembly Binding Log Viewer (FUSLOGVW.exe) . The sample log in Figure 7-5 resulted from an attempt to resolve AcmeGui's reference to a Customer assembly that had a strong name when it was built with a version of the assembly that did not have a strong name:

Figure 7-5. Assembly binding log for customer load failure.

for RuBoard