From: Mr. Arnold on 27 Jun 2010 15:09
> Here are some more questions:
> 1. How can you tell if .Net Remoting over TCP/IP or WCF client/service over
> TCP, Named Piped or MSMQ is being used? Which method is better?
..Net Remoting is a legacy solution that is being replaced by WCF.
What is WCF?
Windows Communication Foundation (WCF) is a framework for building
service-oriented applications. Using WCF, you can send data as
asynchronous messages from one service endpoint to another.
A service endpoint can be part of a continuously available service
hosted by IIS,or it can be a service hosted in an application.
An endpoint can be a client of a service that requests data from a
service endpoint. The messages can be as simple as a single character or
word sent as XML, or as complex as a stream of binary data. A few sample
>> By using .Net Remoting over TCP/IP or WCF client/service over TCP, Named
>> Piped or MSMQ and sending a message to the other project to a service in
>> the other project that is listening.
>> In either case Remoting or WCF, one project is the client and the other
>> project is the service.
> 2. The other person that responded to this e-mail message said the following:
> "By the way, there is absolutely no need to use any kind of remoting,
> networking, message passing, etc. As long as the types are visible in
> the same project (which that itself _is_ related to the project
> references), passing the delegate object is as simple as just passing
> the reference to a method, subscribing to an event, etc. ".
It may be ok and could be the correct method in your situation.
However for you, it would be contingent upon everything happening in the
same project and if not, you may have to explore another approach.
I have not worked in the Windows desktop environment in many years. The
method wouldn't work if projects (dll's) were on physical n-tier
> Thus can you tell me if your way and/or his way are good methods for having
> different projects communicate with each other in the same solution?
It depends upon the circumstances if all the solution components are
deployed to a single machine or deployed/distributed across multiple
If it's all on the same machine, then go with the other poster. But be
aware that WCF is there.
From: Peter Duniho on 27 Jun 2010 17:17
> 1. When looking at a large solution (lots of projects), how can you tell
> where the custom control code is located at?
The Windows command prompt has the "findstr" command, or you can use any
of the many third-party versions of "grep". Visual Studio even has a
"Find in Files" command.
If you are looking for the source code of a particular custom control
type used elsewhere, use one of those text-search tools to look for any
file that has both the type name and the word "class" on the same line
If you do not expect to find the source code for the implementation, but
rather are just looking for a DLL containing the implementation, then
your task is somewhat harder. You can use a tool like Reflector to
examine individual DLLs to see if the type you want is there. But
ideally you'd just have some documentation that says the name of the DLL
you're looking for.
> 2 How can delegate(s) be accessed by code when the reference to a delegate
> are in different projects? (How to you set this up in the .net solution?) How
> do you know if the delegates are in the same project or different project?
As I wrote before, a delegate is simply an instance of a delegate type
that references some particular method. Any code anywhere can create an
instance of a delegate and pass it to any other code. The fact that the
code involved may be in separate projects is completely irrelevant; if
the two projects are being used in the same end project, passing a
delegate from code in one project to code in another project is no
different than if the code was all in the same project.
> 3. I want to make certain that all projects within a soltuion can access
> each other when needed? Basically I want dll's to be accessed when needed
> between projects.
As explained previously, one project refers to another project through
use of the project references. Assuming you have configured the
references correctly, then a project that depends on a DLL will not have
any trouble at all using that DLL.
> I want all delegates between projects to be accessible. How can you tell if
> this is setup correctly?
Frankly, I am not sure you are using the word "delegate" correctly. It
has a very specific meaning in the .NET/C# context, different from the
meaning found in some other contexts. It might be helpful if you would
provide a clear, specific definition of what you think the word