Why doesn't C# Class Library works when I make it an .dll?

Question

0.00/5 (No votes)

See more:

Why doesn't the .dll works?

I use the following code to call it:

C#

using XauSHello;

HelloWorld hello = new HelloWorld();

When I write "hello." it doesn't give me my functions "Talk" and "Speak". Why?

This is the Class Library cs file:

C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using SpeechLib;
using System.Windows.Forms;

namespace XauSHello
{
    public class HelloWorld
    {
        public static void Talk(string p)
        {
            MessageBox.Show(p);
        }

        public static void Speak(string speak)
        {
            SpVoice Voice = new SpVoice();

            Voice.Rate = 1;
            Voice.Volume = 100;
            Voice.Speak(speak);
        }
    }
}

Posted 1-Aug-13 13:27pm

XauS_

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ron Beyer · Accepted Answer · 2013-08-01T13:31:00

Solution 1

Because Talk and Speak are static methods, so you can't call them on an instance. In order to "see" them, you have to use HelloWorld.Talk() or HelloWorld.Speak, not hello.Talk or hello.Speak.

Posted 1-Aug-13 13:31pm

Ron Beyer

Comments

XauS_ 1-Aug-13 19:34pm

Thank you very much!

Ron Beyer 1-Aug-13 19:37pm

By the way, if you only have static methods in a class, you should declare the class as static, that way you can't create instances like you did, it would throw a compiler error and would be a lot clearer on how to fix it.

XauS_ 1-Aug-13 19:39pm

Thanks again! You're awsome!

Sergey Alexandrovich Kryukov 1-Aug-13 19:49pm

Exactly, a 5.
—SA

Sergey Alexandrovich Kryukov 1-Aug-13 19:59pm

By the way, the issue has nothing to do with the fact that it's a DLL or not. If OP wants to work inside one assembly, interanal would work, instead of public.
For .NET there is no essential differences between "EXE", "DLL" or anything else, there are only assemblies and modules.
—SA

Ron Beyer 1-Aug-13 20:34pm

Which leads me to a horrible memory of somebody linking an .exe to another exe so they could use some of the types in the first exe...

Sergey Alexandrovich Kryukov 1-Aug-13 22:21pm

Linking EXE to EXE does not seem to make any sense, but I can give you a very reasonable example when you can reference EXE by a DLL, quite a practical and legitimate. Interested?
—SA

Ron Beyer 2-Aug-13 11:24am

Always interested in special cases, fire away.

Sergey Alexandrovich Kryukov 2-Aug-13 11:54am

Consider the following: you have a simple host application, which accepts one or more types of plug-ins. The best way to invoke a plug-in is to have some plug-in interface implemented in plug-in. Then the host application can easily recognize and instantiate the implementing type by Reflection. It requires that the plug-in interface (and whatever it involves) was visible to all plug-in, as well as to the host application.

Do you have to have the third assembly, referenced by both plug-ins and the host. No! You can simply define it as public type(s) in the host applications. The plug-ins should reference the host ("EXE") assembly. Any circular dependencies? Not really. During the build, the plug-ins are always on the top (they depends on the below layers, nothing depends on plug-in). And the application starts depending on plug-ins only during runtime, only when the are loaded. All is legitimate.

Not even very "special", don't you think so.

—SA

Ron Beyer 2-Aug-13 13:17pm

That certainly is a valid use case for linking that way, however having developed a major pluggable application I prefer to keep the main application as simple as possible and have the interfaces in separate assemblies.

Think of it this way, having the plug-in architecture separate from the main application means that the plug-ins don't depend on the main application to work. Lets say I want to develop a new version of the application, if I have the plug-ins reference the main app then backwards compatibility suffers (much harder to maintain, especially in signed assembly linking), however if I have just an interface I can make a proxy and keep backward compatibility quite easily.

Sergey Alexandrovich Kryukov 2-Aug-13 13:27pm

Well, me too. I just gave an example of the valid case, which can make full practical sense, too. And your considerations on backup compatibility remain valid in this binding. Having as separate assembly with definitions the plug-ins depend on still makes the system more loosely coupled though.
—SA