Is it possible to instantiate an object in Bin folder of a web application remotly?

R

Ray5531

I have a console application in my local computer which I like to use
remoting in it,to instanciate an object (MyClass.dll) in a web
application(its bin folder) in a completely seperated box(in the same domain
thought) .I have two questions:

1)Is my case covered in "Remoting objects hosted in IIS" topic?Are they
same?

2) How should I authenticate to IIS from my console application? Do I really
need to authenticate to IIS before instantiating the object?


Thanks for your help.
 
B

Brock Allen

1)Is my case covered in "Remoting objects hosted in IIS" topic?Are
they same?

Not sure -- your description of the setup is a little unclear. Hosting remoting
objects out of IIS and ASP.NET means you've delpoyed your MarshalByRefObject-derived
classes to an assembly in the ~/bin and you've configured web.config to serve
those up as .rem or .soap endpoints. I'm not sure how your console app fits
into this picture unless it's the remoting client application.
2) How should I authenticate to IIS from my console application? Do I
really need to authenticate to IIS before instantiating the object?

Ah, so the console app is the client. So then on the transparent proxy you
can set the credentials via ((Thx to Mike Woodring for this tip)):

// assuming tp is your transparent proxy
IDictionary chanProps = ChannelServices.GetChannelSinkProperties(tp);
// this uses your client app's credentials
chanProps["credentials"] = CredentialCache.DefaultCredentials;
// or this sets them explicitlly if you have plaintext password
chanProps["credentials"] = new NetworkCredential(userName, password);

Ick. Super ick. Ick Ick Ick.
 
R

Ray5531

Not sure -- your description of the setup is a little unclear. Hosting
remoting objects out of IIS and ASP.NET means you've delpoyed your
MarshalByRefObject-derived classes to an assembly in the ~/bin and you've
configured web.config to serve those up as .rem or .soap endpoints. I'm
not sure how your console app fits into this picture unless it's the
remoting client application.

Yes,The class I want to uuse within the dll file is derived from
MarshalByRefObject and the assembly is in the bin folder of the web
application.The console application is an application which is going to
instantiate that class and uses one of its method to do something.The object
is hosting by IIS.I think having said this ,it means that console
application is remoting client app and IIS hosts the remote object.
Is that right? You mentioned web.config in your reply.which web config are
you refering to?

Let's assume all this done.I would always see the latest version of remote
object in my console app,right? and I do not need to reference it explicity
or be worried about compiling my client app whenevr they compile the
remoting object ,right?


Thanks for your reply.
Brock Allen said:
1)Is my case covered in "Remoting objects hosted in IIS" topic?Are
they same?

Not sure -- your description of the setup is a little unclear. Hosting
remoting objects out of IIS and ASP.NET means you've delpoyed your
MarshalByRefObject-derived classes to an assembly in the ~/bin and you've
configured web.config to serve those up as .rem or .soap endpoints. I'm
not sure how your console app fits into this picture unless it's the
remoting client application.
2) How should I authenticate to IIS from my console application? Do I
really need to authenticate to IIS before instantiating the object?

Ah, so the console app is the client. So then on the transparent proxy you
can set the credentials via ((Thx to Mike Woodring for this tip)):

// assuming tp is your transparent proxy
IDictionary chanProps = ChannelServices.GetChannelSinkProperties(tp);
// this uses your client app's credentials
chanProps["credentials"] = CredentialCache.DefaultCredentials;
// or this sets them explicitlly if you have plaintext password
chanProps["credentials"] = new NetworkCredential(userName, password);

Ick. Super ick. Ick Ick Ick.
 
B

Brock Allen

Let's assume all this done.I would always see the latest version of
remote object in my console app,right? and I do not need to reference
it explicity or be worried about compiling my client app whenevr they
compile the remoting object ,right?

As long as the client and server share some common metadata format, then
yes, this will work. The recommended approach is to use an interface as the
common metadata format. IOW, that's the shared API between the client and
server. This then will basically mean that your MBRO should be configured
as a WellKnown Object type. It's up to you whether you decide to configure
it as SingleCall or Singleton. Mind you, singleton is a misnomer. It just
means there's only evenr one instance at any one time, but it could be a
different instance over time.
 
R

Ray5531

As long as the client and server share some common metadata format, then
yes, this will work

By this you mean the name of the method I'd like to call and also the
signature of it ,right?

I guess my other question is that ,you said "Bin folder" in your reply.I was
reading this article
(http://msdn.microsoft.com/library/d...teobjectsininternetinformationservicesiis.asp)
that I noticed the actual place for the remote objects needs to be in the
bin folder of the WWW root and those server side settings needs to be
inserted into the web.config file of IIS (wwwroot).Here is my problem:

Web portion of our application is in IIS and the object I'd like to remotely
call is always in the Bin folder of our application.I'd like to call that
object and I don;t want any body put the new version of that object to the
Bin folder of IIS whenever it gets changed.Is it possible to do that>


Thanks
 
B

Brock Allen

By this you mean the name of the method I'd like to call and also the
signature of it ,right?

Well, yeah, to compile your client you need to know what it is you're calling.
So the interface based approach is usually the best. Your client references
the assembly that has the interface definition (which is a seperate assembly
from the server itself) and then you get a proxy via RemotingServices.Connect
and cast it to your interface type.
I guess my other question is that ,you said "Bin folder" in your
reply.I was reading this article
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgu
ide/html/cpconhostingremoteobjectsininternetinformationservicesiis.asp
) that I noticed the actual place for the remote objects needs to be
in the bin folder of the WWW root and those server side settings needs
to be inserted into the web.config file of IIS (wwwroot).Here is my
problem:

Web portion of our application is in IIS and the object I'd like to
remotely call is always in the Bin folder of our application.

The ~/bin folder is the bin folder under the root directory of your application
as configured in IIS as a virtual directory. You don't need to deploy it
at the root of the website (but you can).
I'd like
to call that object and I don;t want any body put the new version of
that object to the Bin folder of IIS whenever it gets changed.Is it
possible to do that>

To control what code is deployed into your web application you need to rely
upon standard NT security for that. Make it such that only admins can write
to the ~/bin folder.
 
R

Ray5531

Brock,
Thanks for the nice reply.Your help is really appreciated.

The Bin folder that the actual remoting object resides is the bin folder of
a web application.This web application has a reference to a business logic
layer (which is a dll file ,I'd like to istantiate one of its class memebers
remotely).When they update the business logic layer ,they have to recompile
the Web application and automatically the Business logic layer dll file is
going to be written into the bin folder(the latest version) and by this
mechanism I always make sure that I'm using the latest version of remoting
object in my remoting client application.Dose it make sense?

By the way ,our web application is using NTLM(integrated windows) so I can
use what you wrote to authenticate to the remoting object and then I'm sure
no body else from outside world has access to the remote object.Am I right
here?


Thanks again
 
R

Ray5531

I know that for remoting application,I always need to have remote object dll
in the client side for the compilation to extract metadata of the object
,but I don;t know what you meant by interface -based approach.You mean that
I have to create an interface of the object in the server and implement it
in the remoting object to make sure they always adhere that interface and
the logic might be only changed.Is that what you meant?

Thanks
 
B

Brock Allen

The Bin folder that the actual remoting object resides is the bin
folder of a web application.This web application has a reference to a
business logic layer (which is a dll file ,I'd like to istantiate one
of its class memebers remotely).When they update the business logic
layer ,they have to recompile the Web application and automatically
the Business logic layer dll file is going to be written into the bin
folder(the latest version) and by this mechanism I always make sure
that I'm using the latest version of remoting object in my remoting
client application.Dose it make sense?

Ok, sure. IOW, whenever they recompile evenrything and redeploy they're overwriting
what was there before. I can't tell if you're happy about that or not...
BTW, your MBRO doesn't need to be in the project where all of your ASPX pages
are (I assume you have some of those). It can be in its own assembly that
just has the remoting class. That organization is up to you.
By the way ,our web application is using NTLM(integrated windows) so I
can use what you wrote to authenticate to the remoting object and then
I'm sure no body else from outside world has access to the remote
object.Am I right here?

Just like any other web app, people from the outside world can try to get
to it. But barring some catastrophic security leak or hole, it sounds like
you're going to get the security you're looking for. But in order to to ensure
you've taken all the precautions you need I'd also suggest doing more research
beyond listening to some schmo on a newsgroup :)
 
B

Brock Allen

I know that for remoting application,I always need to have remote
object dll in the client side for the compilation to extract metadata
of the object ,but I don;t know what you meant by interface -based
approach.You mean that I have to create an interface of the object in
the server and implement it in the remoting object to make sure they
always adhere that interface and the logic might be only changed.Is
that what you meant?

Your app needn't be designed that way. It sort of defeats the purpose to
require a copy of the server assembly at the client location. The interface
based approach is very similar, actually, because all the models require
metadata on the client so the runtime can instantiate a transparent proxy.

The interface based approach factors out into a seperate assembly all the
necessary information the client needs at compile time (and runtime). This
is then deployed to the client and that's used to compile. To connect, then,
RemotingServices.Connect(typeof(IInterfaceName), "protocol://server:port/app/endpoint")
is called to get a proxy that implements the interface. The server, of course,
must provide a class that implements the interface and is registered appropriately.


Like I said, it's not too different, but it's a bit cleaner, IMO, as it's
more explicit.
 
R

Ray5531

The interface based approach factors out into a seperate assembly all the
necessary information the client needs at compile time (and runtime). This
is then deployed to the client and that's used to compile. To connect,
then, RemotingServices.Connect(typeof(IInterfaceName),
"protocol://server:port/app/endpoint") is called to get a proxy that
implements the interface. The server, of course, must provide a class that
implements the interface and is registered appropriately.

I think we are both saying the same thing about the interface-based
approach.If you look at this
http://msdn.microsoft.com/library/d...ide/html/cpconRemotingExampleHostingInIIS.asp,
it is using almost the same idea.There is an IService interface which
defines everything.

You mean that I should make a seperate project (class Library) which
contains an interface of what I expect from the remote object and use that
deploy that interface to the client instead of Actual assembly ??? yes you
are right in that case, I don't need to have the actual assembly in the
client (As it is big assembly which is also the subject of daily changes)
and I only deploy the assembly which contains the interface,but having one
extra project for only one interface sucks in a way.Dosen't it? they have
put everything in Business Logic Layer.


Thanks
 
B

Brock Allen

I think we are both saying the same thing about the interface-based
approach.If you look at this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgui
de/html/cpconRemotingExampleHostingInIIS.asp, it is using almost the
same idea.There is an IService interface which defines everything.

Yeah, this is close. Except I don't advocate the use of "new" for remoting
objects. It leads to "sloppy thinking" for those who don't know that they're
working with remote objects.
You mean that I should make a seperate project (class Library) which
contains an interface of what I expect from the remote object and use
that deploy that interface to the client instead of Actual assembly
??? yes you are right in that case, I don't need to have the actual
assembly in the client (As it is big assembly which is also the
subject of daily changes) and I only deploy the assembly which
contains the interface,but having one extra project for only one
interface sucks in a way.Dosen't it? they have put everything in
Business Logic Layer.

Yes, I think a seperate project (assembly) is better as it's more explict.
Trying to take an existing library and "just remote it" leads to disaster,
as the library (set of classes and APIs) weren't designed for the remote
scenario. It's important to design for the task at hand. The business library
should do its thing, and the remoting layer should do another. It's very
hard to get both of those merged into a single API that works really well
for both masters (so to speak).
 
R

Ray5531

Yeah, this is close. Except I don't advocate the use of "new" for remoting
objects. It leads to "sloppy thinking" for those who don't know that
they're working with remote objects.

This is what you advocate ? -->
RemotingServices.Connect(typeof(IInterfaceName),
"protocol://server:port/app/endpoint")


Thanks
 
B

Brock Allen

This is what you advocate ? -->
RemotingServices.Connect(typeof(IInterfaceName),
"protocol://server:port/app/endpoint")

Yes, except of course you'd want to substiture your interface name and the
URI for your particular server. And also you'd probabaly want to store the
URI in your client's config file and load it via ConfigurationSettings.AppSettings,
but other than that, yes. Mind you, this is the API for WellKnownObject configuration
and won't work with ClientActivatedObjects.

Is there something unappealing about this to you?
 
R

Ray5531

Brock ,

Your explanations where awesome and I learnt a lot.Thanks for your patience
and help.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top