[scolty]

Morning,

Im a little confused as to how one would go about deploying a program which uses multiple DLL's. If ive understood correctly, the user needs to perform some form or setup prior to being able to run the executable using several DLL's?? Ive had a look online and in c# 4.0 in a nutshell, specifically regarding "packing a single-file executable but am still confused.

Quote

its also good to be able to pack the whole thing (he is refering to 1 executable and several assemblies) into a single click and run executable-without demanding the user perform some setup or file extraction ritual.

It states that this is possible by including the compiled assembly DLL's in the main exectuable project as embedded resources, and then writting an assemblyresolve event handler to load their binary images on demand.

using System;
using System.IO;
using System.Reflection;
using System.Collections.Generic;

public class Loader
{
  static Dictionary <string, Assembly> libs
   = new Dictionary <string, Assembly>();

  static void Main()
  {
    AppDomain.CurrentDomain.AssemblyResolve += FindAssem;
    Program.Go();
  }

  static Assembly FindAssem (object sender, ResolveEventArgs args)
  {
    string shortName = new AssemblyName (args.Name).Name;
    if (libs.ContainsKey (shortName)) return libs [shortName];

    using (Stream s = Assembly.GetExecutingAssembly().
           GetManifestResourceStream ("Libs." + shortName + ".dll"))
    {
       byte[] data = new BinaryReader (s).ReadBytes ((int) s.Length);
       Assembly a = Assembly.Load (data);
       libs [shortName] = a; 
       return a;
    }
  }
}

public class Program
{
  public static void Go()
  {
    // Run main program...
  }
}

The following link then states the following:

Quote

A single project

If all parts of your program are written by yourself in the same language, you can obviously just add all source files to a single project. The result will be a single DLL or EXE containing all dependencies.

csc /target:winexe /out:Program.exe 
      MainProgram.cs ClassLibrary1.cs ClassLibrary2.cs 

However, if your program is written in multiple languages or if you are using binary third party libraries, you are out of luck.

Are they both talking about the same thing or am i missing something??

Thanks for your time.

[Curtis Rutland]

Well, first of all, they're not talking about the same thing. The second is talking about compiling multiple files into a single assembly. C# code can be broken across several files for the ease of human reading and organization. However, these files still belong to the same project, and as such, will all be part of the same output; namely a .DLL or a .EXE, depending on the project type.

By the way, Visual Studio does that part for you. When you Build (or Rebuild, or Debug), it handles calling csc.exe for you and compiling your code files into an output DLL/EXE.

The first part is talking about embedding other dependent DLLs as resources into the executable itself. It's a bit tricky.

Before you go on here, I have to ask, do you understand what DLLs are for, from the perspective of .NET? If not, say so, and I'll explain more. Otherwise, keep reading.

.EXEs can have resources embedded in them. These can be text files, images, anything that can be represented as binary data. And it's possible for the executable to create a Stream to its own resources. Also, it's possible for an executable to run custom code to resolve assemblies, and to resolve them from a stream.

The sum of all these parts is that a program can embed DLLs in itself, and load them out at runtime.

It's usually not necessary, since you can just package your exe and dlls into an installer that will install them all at once.

[scolty]

Hey Curtis, Firstly thanks for replyin.

DLL's (as far as im aware) are dynamic linked libraries. Basically allows you to break a program down into several seperate files so for example, several people could be working on the same program. You then add references to them in your project file containing the Main() method. The DLL's can have strong and weak names. Strong names require a public/private key pair and usually good to use this once you have finished developing. weak named assemblies dont need the key pair and you mainly use it when developing. Strongly naming an assembly only allows you to see that it hasnt been messed with, not that that it doesnt contain something which will screw ur pc up as the hash values only get checked.

Im assuming the above is correct. If not, id really appreciate it if you pointed out where im wrong + the explainations are just off the top of my head so they probably arent the nicest.

My knowledge of actually deploying applications is ... well pretty limited hence the questions below.

Quote

The first part is talking about embedding other dependent DLLs as resources into the executable itself. It's a bit tricky.

Ok, so basically i can forget about the first part. All id like to be able to do is have an executable and either one or several .dll's which i send to someone and they can run my program.

I have no clue what a stream is, havent come across that before but im assuming i dont need to worry about it atm for the above aim?

Whats the benefit of having the DLLs embeded within a program and loading the DLLs at runtime? Is it just so u have one single file?

You mention an installer at the very end. Could you please elaborate. Is this part of VS or something id have to write??

Thanks again bro

[Curtis Rutland]

Quote

Basically allows you to break a program down into several seperate files so for example, several people could be working on the same program.

Yes and no. DLLs are basically chunks of functionality. They don't necessarily have to relate to any specific program. Think of them almost as components.

For example, let's say I wrote a better version of String (purely for example). I want many projects and even other people to be able to use my version of String. So, instead of writing it in my Console Application or Windows Form application, I write it in a "Class Library" project. The output of a class library is a DLL. It's structured similarly to an executable, except there is no Main method. DLLs can't be "executed" on their own. They expose classes and interfaces to other programs.

As to allowing several people to work on the same program: you don't have to use DLLs for that. You can break programs across several files and still have it be part of the same assembly that's generated. If you add multiple classes in multiple files into your project, they're still part of the same program, not separate DLLs.

So, that in mind, I have to ask, what's your goal here? Do you really need multiple assemblies? One of the ideas behind DLLs is that if you have some functionality you might want to use for several projects, you put that functionality into a Class Library project. The output is a DLL. Then, when you need another program to use that same set of functionality, you add a reference to the DLL, and you don't have to re-write it or even copy/paste it.

If, however, you're just writing this stuff for this project only, there's no real need to separate it out.

---

As to embedding DLLs into your executable...I've never found a need for it. I suppose the benefit is to have everything wrapped up in one single executable file, but I've never needed that. It's far more trouble than it's worth, for anything I've done.

As to installers, the paid versions of Visual Studio come with a project called a Setup Project. It allows you to build installers. Installers are programs that take the output of your project and put them in the Program Files folder, and let you add Desktop/Start Menu shortcuts, along with many other features.

All versions (including Express) also allow you to "Publish" your projects using "Click Once." You can read more about that here:

http://msdn.microsof...(v=VS.100).aspx

Click Once is simpler in a lot of ways, and convenient, but not up to every task. Read up on it to see if it'll do what you need.

[RexGrammer]

OK If you just searched our tutorials you would come over this tutorial: SETUP AND DEPLOYMENT IN VISUAL STUDIO 2010:.

And just to point you in the right direction for streams:
Streams and .NET (CodeGuru Article)
Stream Class (MSDN Article)

[scolty]

Curtis: Ive was under the impression that DLL's and Assemblies were the same thing... Just to clarify, Assemblies can be either DLL's or executables right?

I was told to make everything modular so im assuming that means using DLL's?

Thanks very much for the link about click once. Ill have a read through it n see if i get it.

RexGrammer: Thanks for the link bro.

[RexGrammer]

No prob...

Well when they say modular it means it can be striped into pieces that can be used in some other project (So yes it means DLL)

Some info on assemblies:

.NET assembly (WIKI Article)
Assemblies Overview (MSDN Article)
What are assemblies? Describe the types of assemblies. (www.careerride.com Article)

This post has been edited by RexGrammer: 12 December 2011 - 12:51 PM

[scolty]

Thanks again RexGrammer

[scolty]

Good morning,

Is it possible for two strongly named assemblies to have the same name, ie a naming conflict?
As far as iam aware, a strongly named assembly consists of the following:

• Its Simple Name
  
• Its Version
  
• Its Culture
  
• Its Public Key Token

So if i have two assemblies with the same CIL code, same file name, using my public/private key pair to sign it, and i dont change the version number ie its the same as on the previous build and its doesnt contain "*" so it doesnt auto-generate a unique version number. Will they have the same name??

Thanks for ur time.

[RexGrammer]

You can read this article:
.NET assembly (WIKI Article)

Among other things it says:

Quote

The public key token is used to make the assembly name unique. Thus, two strong named assemblies can have the same PE file name and yet .NET will recognize them as different assemblies.

[scolty]

Morning RexGrammer,

Yeah but im assuming that only applies when the versioning is different? Anyway, i had a look at ur link n its only applicable to GAC anyway since u obv cant store two assemblies with the same name in a windows folder.

Thanks again for the link + clearing up the confusion.

[RexGrammer]

I think it doesn't assume the versioning is different, because the public key is always unique...

And if you read it more carefully:

Quote

To solve this issue .NET introduces the GAC (Global Assembly Cache) that is treated as a single folder by the .NET CLR, but is actually implemented using nested file system folders.

The GAC is implemented using nested file system folders, but it's being treated as a single folder, and the 'To solve this...' is referring to the problem that you can't have two assemblies with the same name in a same windows folder...

[scolty]

hey,

Thanks for replying. the below links seem to suggest otherwise??

http://bytes.com/top...ges-rebuild-all

http://www.pcreview....s-t1344484.html

suggests that they arent unique unless u create a unique pair each time. I may be wrong though but i remember reading something somewhere about how many key pairs you should have as well.

let me know what u think.

This post has been edited by scolty: 13 December 2011 - 03:54 AM

[RexGrammer]

Just a tip you can see how your post will look with the preview post button!

Again I would trust WIKI over anything (but that's just me)

My interpretations of the links:

http://bytes.com/top...ges-rebuild-all

Nope this doesn't say otherwise. That question has very little to do with this, he is asking why does his keys change (since he is providing a same key pair), the reason was because he was using 'sn -t' to display the token instead of 'sn -T'...

http://www.pcreview....s-t1344484.html

Quote

This also makes the
assembly name globally
unique because no other developer will be using the same 1,024-bit public
key as part of their assemblies' name.

It says the 1024-bit public key is always unique...

That is said in many parts of that link I was just too lazy to quote them all.

You may have dipped into something you're not ready yet. You should read a C# book from cover-to-cover before trying to do some advanced topics. And how could you have two assemblies with the same version, name and key? It's just very little likely in the real world.

This post has been edited by RexGrammer: 13 December 2011 - 04:09 AM

[Curtis Rutland]

It's only unique if you create a new key. If you use the same key file to sign the same assembly with the same version...it's got the same strong name, because it's the same assembly.