Is this possible? Equivalent of C++ header file?

[Adam Clauss]

OK, lets say I have a C# Windows application. In it is a a series of
namespaces, all rooted for a certain namespace A.

For ex, the "using" directives would read something like:
using A;
using A.somenamespace;
using A.anothernamespace;

Now, other users will be using these namespaces. I would like for them to
be able to take advantage of the intellisense features in Visual Studio, but
I do not want to actually give them the source code (or give them a DLL with
the necessary files). In other words, I want them to be able to code using
it, but not actually be able to run it (does that make sense? I know it
seems a little wierd). In C++, this would simply be done by creating a
header file. Unfortunately, I'm not familiar enough with C# to know how to
go about doing something similar.

So, is there anyway that this can be done?

 

[mikeb]

OK, lets say I have a C# Windows application. In it is a a series of
namespaces, all rooted for a certain namespace A.

For ex, the "using" directives would read something like:
using A;
using A.somenamespace;
using A.anothernamespace;

Now, other users will be using these namespaces. I would like for them to
be able to take advantage of the intellisense features in Visual Studio, but
I do not want to actually give them the source code (or give them a DLL with
the necessary files). In other words, I want them to be able to code using
it, but not actually be able to run it (does that make sense? I know it
seems a little wierd). In C++, this would simply be done by creating a
header file. Unfortunately, I'm not familiar enough with C# to know how to
go about doing something similar.

So, is there anyway that this can be done?

In C#, the assembly is used to get the information that C/C++ compilers
used header files for. So to get intellisense, the coders need an
assembly of some sort.

Probably the cleanest way to do what you appear to want to do is to have
all of the methods you want them to code against be interfaces. That
way, you can compile an assembly that has nothing but the interface
declarations - no implementation code would be in that assembly.

They can reference that assembly for intellisense.

Your code with the classes that implement the interfaces would reference
the same assembly.

One drawback to this is that interfaces cannot contain static methods.
This might also require a big change in the design of whatever you're doing.

Another option might be to use #if/#endif conditional compilation to
build version of your assemblies that have no real implementation. They
can code against those assemblies, then submit the code to whomever to
build against assemblies that have real implementations. I'm not sure
how well this would really work.

 

[Adam Clauss]

Hmm I was afraid it might not be easy

I'll look into those methods, see if either is doable.

I agree that the first method would be the 'best' to implement,
unfortunately it may be too late to go through and change that at this
point.

What I'm trying to accomplish here:
The app in question (not open source) compiles various scripts at runtime.
For users designing these runtime scripts, I would like for them to have
available all the classes, methods, etc in intellisense for them to use -
Right now they just have to memorize everything.

They cannot and do not need to actually BUILD against my assembly - the
program does that itself at runtime.

 

[Nick Malik]

Adam,

It is not difficult to create an interface. It is very much like a header.
You create a new project, create the interface objects (like class
definitions, but containing no method code), and compile it. You distribute
the resulting DLL.

To be certain that you are meeting the same interface expectations, you
should derive your objects from the same definitions.
Depending on the number of classes, this can take a little while, but not a
terribly long period of time. You should be able to create an interface for
each exposed class at a rate of one per 10-15 minutes. If you expose 80
classes, you can do this in a few days... (Really... count your classes...)
If you were prepared to create header files, you can create interfaces.

For the interfaces that require static methods, simply create a "shell"
class (perhaps using the #ifdef idea that mikeb suggests) and include it in
an alternate assembly (for ease of deployment).

One advantage to interface objects for the future: your users CAN compile
the code themselves... and you can call the code with confidence knowing
that it meets your requirements.

Good Luck,
--- Nick

 

[Adam Clauss]

Well, it isn't so much that I was prepared to go through and make header
files - but I was just using that as an example. Ideally I was hoping there
was some way I could generate some sort of... something.
AKA: take the assembly from my program, pass it through some tool or option
from Visual Studio and "extract" the parts from the namespace I need.

At first I thought the tlbexp might do just what I wanted... but after a
little research it seems it is just for COM projects. I was able to
generate a .tlb file with no problem, but I could not add a reference to
that file .tlb file in another project.

I will look into what I've been given here though.
Thanks for the suggestions.