By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,065 Members | 1,598 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,065 IT Pros & Developers. It's quick & easy.

Accessing a C# delegate used in a C# interface....

P: n/a

I'm currently developing on a large project where several assemblies
build into DLLs that support the final .NET EXE. The original plan was
to implement the project in VB.NET, so the EXE project is a VB WinForms
App. Later on we got approval to not stick to that requirement so I
started writing library code in C# (which I much prefer).

Of interest in my problem are two C# DLL projects aside from the main
EXE project. The first, we'll call it 'A', contains a code file with a
few general no-arg delegate declarations. Then, an interface in the
other C# project, which we'll call 'B', contains declarations of events
using this delegate-type.

Finally, one of the Forms in the VB EXE implements this interface and
thus implements the events from the C# interface in assembly B. This
seemed to work okay earlier and not give any errors, but perhaps other
errors that I have since resolved were blocking the notification of
these errors, so the problem could have been there all along since I
started using the delegates/interfaces. I'm not entirely sure on that.

If I build assembly A or B separately, I get no problems. They compile
entirely. Remember that the interface in B, uses the delegate in A, so
it can see it and use it fine according to the C# compiler. Then I try
building the VB EXE and it complains, saying

C:\MyPath\MainForm.vb(16707566): Type 'A.EventHandler' is not defined.

Obviously my code is not that long. The vb compiler made up that line
number, presumably as some default abstract designation. I'm not for

Yet I am not getting an error that says I am failing to implement the
interface. This is curious because the only way it can know that I am
correctly implementing the interface is if it knows about that
delegate-type. Before I fixed other problems, I was getting a compiler
error that told me I wasn't yet implementing the interface when I was
mismatching on some of the declarations between VB and C#. Once I fixed
those, those went away. So that error was accurately reflecting that
issue. So what could have occurred that it suddenly doesn't find a
declaration that had to have been used to help resolve another error

All dependency references are project references (as opposed to
explicit DLL path references) and yes I've tried deleted all bin/obj
folders and then rebuilding.



Nov 21 '05 #1
Share this Question
Share on Google+
4 Replies

P: n/a
Just an off the wall comment. What is the versioning in the
AssemblyInfo.vb set to? Is it set to auto increment the version?
Could this be related to your problem?

Nov 21 '05 #2

P: n/a
If by "auto increment" you mean that the version ends with a wildcard,
then yes. In AssemblyInfo.vb I have:

<Assembly: AssemblyVersion("0.4.0.*")>

Does it matter that I've pushed the wild-card to the fourth component,
instead of the default third often used? I do this so I can explicitely
specify major-minor-micro versions and just let that final
auto-component be my IDE-generated "build-number".

How would this cause the problem I describe above though? Thanks.


Nov 21 '05 #3

P: n/a
My idea is that perhaps the error you are getting is caused by a
mismatched version. I have read in Jeffrey Richter's book, "Applied
Microsoft .Net Framework Programming" that using the wildcard to
specify the version can cause dependency problems and that you should
always specify all four values.

I don't know if this is your problem, but it may be worth looking at.


Nov 21 '05 #4

P: n/a
Unfortunately this is not it. I deleted all build output again, removed
all wildcards from versions, specifying all parts explicitely, and the
result hasn't changed. Thanks for the suggestion though, I would agree
it was worth trying, seeing as how I can make little more sense of what
I'm experience.

So I'm open to other possibilities again. Thanks.


Nov 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.