Basic .NET strategy

[Grant Schenck]

Hello,

I'm pretty new to C# and .NET.

I've been tasked with creating an Internet Explorer toolbar. I implemented
it and it works OK, however, because the toolbar has a notion of having to
log into an account and do other time consuming initialization, the result
is that IE takes around 5 seconds to start each time a browser window is
opened.

So, what makes sense is to have some separate service or server which runs
at startup and takes care of the time consuming initialization. Then, once
we are rolling, when IE starts with my toolbar, the toolbar would talk to
the service to carry out the work it needs to.

So, I'm looking for archetectural advice:

- How would it make sense to package my service? As a true NT Service or as
some kind of task bar application?
- How should my toolbar and service comminicate? These would both be
running on the same PC but I'm not sure what the issues are with regard to
managed code and IPC.
- Are there any C# .NET samples which demonstrate some of the approrpriate
techniques? If so, where?

Thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Grant,

I think that splitting this out into a service is a bunch of overhead to
minimize a five-second operation. Have you thought about performing the
login asynchronously when the toolbar is created? This could be an
acceptable alternative (after all, does the toolbar do something when
loaded, or does it wait for user interaction? If it waits for user
interaction, performing the operation asynchronously might be what you
need).

If you decide to go the route with the service, then here are the
answers for your questions:

- How would it make sense to package my service? As a true NT Service or as
some kind of task bar application?

I would package it as a service. However, you have to make sure that
this is pretty stateless (your credentials to log in would have to be passed
to the service, because of the possiblity of multiple sessions running on
the same PC).

- How should my toolbar and service comminicate? These would both be
running on the same PC but I'm not sure what the issues are with regard to
managed code and IPC.

I would use remoting for this instance. If it's on the same machine,
with .NET 2.0, you can use the cross-process channel (IPC) which is pretty
fast.

- Are there any C# .NET samples which demonstrate some of the approrpriate
techniques? If so, where?

There should be some samples in the MSDN documentation for .NET under
the Remoting section.

You should note that the overhead of creating the service and
communicating with that might be more than the overhead of the login. You
will have to perform some tests to see which is more performant, and then
make the decision which is more acceptable.

Hope this helps.

 

[Grant Schenck]

Wow! That was fast.

OK, I'm flopping about and by no means committed to the service idea.
Actually, you initial solution may be the way to go, that is handling the
login aspects asyncronously. I'll dig into that idea and get back if I want
to continue the service aspects.

Thank you very much.
--
Grant Schenck

Grant,

I think that splitting this out into a service is a bunch of overhead to
minimize a five-second operation. Have you thought about performing the
login asynchronously when the toolbar is created? This could be an
acceptable alternative (after all, does the toolbar do something when
loaded, or does it wait for user interaction? If it waits for user
interaction, performing the operation asynchronously might be what you
need).

If you decide to go the route with the service, then here are the
answers for your questions:

- How would it make sense to package my service? As a true NT Service or as
some kind of task bar application?

I would package it as a service. However, you have to make sure that
this is pretty stateless (your credentials to log in would have to be passed
to the service, because of the possiblity of multiple sessions running on
the same PC).

- How should my toolbar and service comminicate? These would both be
running on the same PC but I'm not sure what the issues are with regard to
managed code and IPC.

I would use remoting for this instance. If it's on the same machine,
with .NET 2.0, you can use the cross-process channel (IPC) which is pretty
fast.

- Are there any C# .NET samples which demonstrate some of the approrpriate
techniques? If so, where?

There should be some samples in the MSDN documentation for .NET under
the Remoting section.

You should note that the overhead of creating the service and
communicating with that might be more than the overhead of the login. You
will have to perform some tests to see which is more performant, and then
make the decision which is more acceptable.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello,

I'm pretty new to C# and .NET.

I've been tasked with creating an Internet Explorer toolbar. I
implemented
it and it works OK, however, because the toolbar has a notion of having to
log into an account and do other time consuming initialization, the result
is that IE takes around 5 seconds to start each time a browser window is
opened.

So, what makes sense is to have some separate service or server which runs
at startup and takes care of the time consuming initialization. Then,
once
we are rolling, when IE starts with my toolbar, the toolbar would talk to
the service to carry out the work it needs to.

So, I'm looking for archetectural advice:

- How would it make sense to package my service? As a true NT Service or
as
some kind of task bar application?
- How should my toolbar and service comminicate? These would both be
running on the same PC but I'm not sure what the issues are with regard to
managed code and IPC.
- Are there any C# .NET samples which demonstrate some of the approrpriate
techniques? If so, where?

Thanks!

 

[Grant Schenck]

I asked this earlier but my description was pretty general...

 

[Nicholas Paldino [.NET/C# MVP]]

Grant,

This is the same post you posted last time. What was missing in the
responses to that post?

 

[Grant Schenck]

Because I'm an idiot! ;-)

I remember now I saw the response but I got pulled off onto another project
so now when I went to revisit it I forgot that I had seen a response.

In any case, I'm proceeding with the idea of the toolbar separate from the
server. I'm actually going to package the "server" as a tray icon program
run by the user. In that regard, is remoting the way to go for
commumication between the tray icon program and tool bar instances? I'm
comfortable with TCP/IP. Is that a viable option for intra machine
client/server apps like mine?

Thanks!
--
Grant Schenck
http://grantschenck.tripod.com

Grant,

This is the same post you posted last time. What was missing in the
responses to that post?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I asked this earlier but my description was pretty general...
or
as

 

[Kevin Yu [MSFT]]

Hi Grant,

To communicate between 2 processes, I suggest you use remoting since you're
using C# as the language. Because using TCP/IP, you have to write from the
low level socket. Also the data might be blocked by firewall. You can check
the following link for more information and examples for .net remoting.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconbuildingbasicnetremotingapplication.asp

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Grant Schenck]

Thanks!

I'm looking at remoting now.

With regards to remoting, I have a need for my server (the tray icon) to
notify the client (the toolbar) in certain scenarios. I also need to "know"
when a given client shuts down. Do you know if remoting will allow this
level of control? Is remoting session oriented?

If either of these is an issue, what other .NET IPCs could I look at?

Regards,

 

[Kevin Yu [MSFT]]

Hi Grant,

Since your server and client are on the same machine, I suggest you add
something in the destructor of the class to inform whether a client has
disconnected. Because before the remote object at server side is GCed, the
connection is always open. So when the destructor of the class is called,
the certain object is GCed.

Also, there are 3 types of remoting objects. Single Call, Singleton and
Client-Activated Objects. Please check the following link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/introremoting.asp

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Grant Schenck]

Thanks! Digging into that now.

I must say, this seems like a massive overkill for what I want to get done.

I have two or more processes running on the same PC. A server and one or
more clients. The clients connects to the server and then I need a simple
way to send messages between the two. The messages can be sent from either
side and no response is required or expected.

Surely .Net provides some kind of simple message based IPC...?

Thanks,

 

[Kevin Yu [MSFT]]

Hi Grant,

There are many other ways you can use for IPC.

Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets

All of them can be used in .NET. But .NET remoting seems to be easy to use.
You can check the following link for IPC on Windows platform.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/in
terprocess_communications.asp

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Grant Schenck]

Thank you sir.

In the end I went with sockets as they seemed the most straight forward.

Regards,

 

[Kevin Yu [MSFT]]

You're welcome, Grant.

Thanks for sharing your experience with all the people here. If you have
any questions, please feel free to post them in the community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."