|
|
You're in the
dotnet remoting
group:Does Remotable assembly is loaded in both Client & Server sides?
dotnet remoting:
There is something basic in .NET Remoting that I am missing: I have created some simple Remoted type (MarshalByRefObject ,with custom Host), which was referenced by simple client application. During the development all the modules were locally and when I referenced my Remoted assembly by the client it was copied to my Client debug folder. In order to run my application, I copy my Remoted assembly to some other computer. However, when activate my remoted assembly, my local remoted assembly is loaded as well (I can see it in MSVC output window and in process explorer); moreover, when I delete the local remoted assembly the client throws an exception. My first thought was that I have initially to reference the remote assembly remotely, but it seems that in MSVC only Web Services, which I can reference that way. In addition, I am sure that the remoted instance of my assembly is running, so here there is no confusion. Any help would be appreciated. Thanks
[quoted text, click to view] >-----Original Message----- >Hi ! > >There is something basic in .NET Remoting that I am missing: > >I have created some simple Remoted type (MarshalByRefObject ,with >custom Host), which was referenced by simple client application. >During the development all the modules were locally and when I >referenced my Remoted assembly by the client it was copied to my >Client debug folder. In order to run my application, I copy my Remoted >assembly to some other computer. However, when activate my remoted >assembly, my local remoted assembly is loaded as well (I can see it in >MSVC output window and in process explorer); moreover, when I delete >the local remoted assembly the client throws an exception. My first >thought was that I have initially to reference the remote assembly >remotely, but it seems that in MSVC only Web Services, which I can >reference that way. In addition, I am sure that the remoted instance >of my assembly is running, so here there is no confusion. > >Any help would be appreciated. > >Thanks > >Jean >. >Jean, I believe that this is the answer you seek. First, let me make sure I have this correct. You are deploying the same dll with both your client app and the custom server app. You want to know "why the client loads the whole dll into its memory", since the client is using the remoted classes from the server. The client loads the whole dll so that it has all of the class information needed to make the server's copy of the classes work, in the server's memory space (to be able to create a proxy instance in the client's memory space that is used to make calls on the server's remoted object's public member functions). You could, feasably build two different dlls, where the one that the client uses merely has empty (do nothing) functions (for the public methods). However, be careful if you do this. Only the public members of a class are remoted!!! Therefore, any non-public member functions you may have written actually run from the client's copy (the proxy) of the class that is loaded into the client's memory space (and non-public data members will also be found in the proxy, not at the server). The clients proxy for this remote object will actually contain all non- public member method implementations and the non-public member data. Let's take a sample to show how wierd this can get. We develop a remotable class that has a private method that changes a public data member. We deploy this class in a dll that both the client and the server apps will have available on their machines. Next, the client app creates an instance of our class (a proxy in the client's memory space) and calls our private method in that class. The private method will execute at the client machine (because it is going to run in the proxy). When it gets to the instruction that assigns a value to the public data member, this private method will make use of the proxy to make that assignment at the server's instance of the remotable object, because that data member was public (and therefore part of the server's instance of our remotable class). It can get a lot stranger if you begin to think about it. Stick tightly to the KISS Principle (Keep It Simple Stupid). The purpose of writing software is to simplify complex operations. Often times, we programmers will make such a complex solution (being cute) that our solution is worse than the original problem. Unless memory at the client machine is a problem, I cannot imagine why a person would build two different versions of a dll. I am sure there are other reasons than just limited memory that may be cause for consideration. However, maintaining two parallel projects and keeping changes synchronized in both would be a headache I would not want, unless it was proved to be absolutely necessary. I hope this helps,
[quoted text, click to view] >-----Original Message----- 1) Obviously, private methods can only be called by the > >"Mike Sheely" <honcho@microag.com> wrote in message >news:00e701c36f34$ebe5e300$a601280a@phx.gbl... >> > >-----Original Message----- from Jean Stax removed for brevity > >> >> You could, feasably build two different dlls, where the >> one that the client uses merely has empty (do nothing) >> functions (for the public methods). However, be careful >> if you do this. Only the public members of a class are >> remoted!!! Therefore, any non-public member functions you >> may have written actually run from the client's copy (the >> proxy) of the class that is loaded into the client's >> memory space (and non-public data members will also be >> found in the proxy, not at the server). The clients proxy >> for this remote object will actually contain all non- >> public member method implementations and the non-public >> member data. >> >> Let's take a sample to show how wierd this can get. We >> develop a remotable class that has a private method that >> changes a public data member. We deploy this class in a >> dll that both the client and the server apps will have >> available on their machines. Next, the client app creates >> an instance of our class (a proxy in the client's memory >> space) and calls our private method in that class. > >How can you invoke a method from outside an object if this method is private >? > >> The private method will execute at the client machine (because >> it is going to run in the proxy). When it gets to the >> instruction that assigns a value to the public data >> member, this private method will make use of the proxy to >> make that assignment at the server's instance of the >> remotable object, because that data member was public (and >> therefore part of the server's instance of our remotable >> class). It can get a lot stranger if you begin to think >> about it. >> >> Stick tightly to the KISS Principle (Keep It Simple >> Stupid). The purpose of writing software is to simplify >> complex operations. Often times, we programmers will make >> such a complex solution (being cute) that our solution is >> worse than the original problem. >> >> Unless memory at the client machine is a problem, I cannot >> imagine why a person would build two different versions of >> a dll. I am sure there are other reasons than just >> limited memory that may be cause for consideration. >> However, maintaining two parallel projects and keeping >> changes synchronized in both would be a headache I would >> not want, unless it was proved to be absolutely necessary. >> >> I hope this helps, >> SheelyCritter > >I'm hard at trying to understand. At first place you say that deploying the >original assembly on the client with private methods might lead to strange >behavior under certain circumstances. This looks like advocating to deploy a >"special" assembly with those private methods trimmed out. Next, you call >for applying the KISS principle which I understand to promote the exact >opposite attitude !!! > >In several projects I have been working on, we decided to deploy a "special" >assembly. One of the reason is we didn't want to release the body of the >private methods for both IP and security reasons. Howevere, we were also >concerned about simplicity and robustness. The way we decided to handle it >was through Visual Studio project. Here is how we did under VS .Net. > >Project 1 is the server side assembly. Let's say we have the Remotable.cs >file in it. > >Project 2 is the client side version of the library produced by Project 1. >In project 2 we don't create any file but reference files from Project 1 >using the Add / Add Existing Item ... and choosing the "Link File" option >under the "Open" button. > >Next we modified the "Assembly Name" property in "Common Properties" / >"General" panel in Project 2 and gave the same name than the one in Project >1. > >Next we added a "TRIM_OUT" conditional compilation constant in the >"Conditional Compilation Constants" property from the "Configuration >Properties" / "Build" panel in Project 2. > >We also modified each method in Project 1 so that it looks like > >public void Method() >{ >#if (TRIM_OUT) >#else > // Real body for Project 1 only. >#endif > return; >} > >For methods returning an object reference, we have : > >public object Method() >{ >#if (TRIM_OUT) > return null; >#else > // Real body for Project 1 only. > return result; >#endif >} > >The source code of every private and protected method in the source file is >also wrapped into the following conditional compilation directive : > >#if (!TRIM_OUT) >private void Method() >{ > ... >} >#endif > >Now we add a reference to Project 2 in client application and a reference to >Project 1 in server application. > > >. >JIP, object itself. 2) I did not promote Chaos, merely demonstrated how easy it is to get there if you don't make an effort to adhere to KISS. 3) If you don't like my answer, ignore it. 4) Why does the RemoteableTypes.DLL file need to be different at the client and server? If there is no valid reason for deploying different files, don't do it. This merely adds confusion. 5) You must include the body of the private functions in the proxy (at the client), because those are not made available via the remoted object. Only public members are remoted.
[quoted text, click to view] "Mike Sheely" <honcho@microag.com> wrote in message news:00e701c36f34$ebe5e300$a601280a@phx.gbl... > -----Original Message----- from Jean Stax removed for brevity [quoted text, click to view] > > You could, feasably build two different dlls, where the > one that the client uses merely has empty (do nothing) > functions (for the public methods). However, be careful > if you do this. Only the public members of a class are > remoted!!! Therefore, any non-public member functions you > may have written actually run from the client's copy (the > proxy) of the class that is loaded into the client's > memory space (and non-public data members will also be > found in the proxy, not at the server). The clients proxy > for this remote object will actually contain all non- > public member method implementations and the non-public > member data. > > Let's take a sample to show how wierd this can get. We > develop a remotable class that has a private method that > changes a public data member. We deploy this class in a > dll that both the client and the server apps will have > available on their machines. Next, the client app creates > an instance of our class (a proxy in the client's memory > space) and calls our private method in that class. How can you invoke a method from outside an object if this method is private ? [quoted text, click to view] > The private method will execute at the client machine (because > it is going to run in the proxy). When it gets to the > instruction that assigns a value to the public data > member, this private method will make use of the proxy to > make that assignment at the server's instance of the > remotable object, because that data member was public (and > therefore part of the server's instance of our remotable > class). It can get a lot stranger if you begin to think > about it. > > Stick tightly to the KISS Principle (Keep It Simple > Stupid). The purpose of writing software is to simplify > complex operations. Often times, we programmers will make > such a complex solution (being cute) that our solution is > worse than the original problem. > > Unless memory at the client machine is a problem, I cannot > imagine why a person would build two different versions of > a dll. I am sure there are other reasons than just > limited memory that may be cause for consideration. > However, maintaining two parallel projects and keeping > changes synchronized in both would be a headache I would > not want, unless it was proved to be absolutely necessary. > > I hope this helps, > SheelyCritter I'm hard at trying to understand. At first place you say that deploying the original assembly on the client with private methods might lead to strange behavior under certain circumstances. This looks like advocating to deploy a "special" assembly with those private methods trimmed out. Next, you call for applying the KISS principle which I understand to promote the exact opposite attitude !!! In several projects I have been working on, we decided to deploy a "special" assembly. One of the reason is we didn't want to release the body of the private methods for both IP and security reasons. Howevere, we were also concerned about simplicity and robustness. The way we decided to handle it was through Visual Studio project. Here is how we did under VS .Net. Project 1 is the server side assembly. Let's say we have the Remotable.cs file in it. Project 2 is the client side version of the library produced by Project 1. In project 2 we don't create any file but reference files from Project 1 using the Add / Add Existing Item ... and choosing the "Link File" option under the "Open" button. Next we modified the "Assembly Name" property in "Common Properties" / "General" panel in Project 2 and gave the same name than the one in Project 1. Next we added a "TRIM_OUT" conditional compilation constant in the "Conditional Compilation Constants" property from the "Configuration Properties" / "Build" panel in Project 2. We also modified each method in Project 1 so that it looks like public void Method() { #if (TRIM_OUT) #else // Real body for Project 1 only. #endif return; } For methods returning an object reference, we have : public object Method() { #if (TRIM_OUT) return null; #else // Real body for Project 1 only. return result; #endif } The source code of every private and protected method in the source file is also wrapped into the following conditional compilation directive : #if (!TRIM_OUT) private void Method() { ... } #endif Now we add a reference to Project 2 in client application and a reference to Project 1 in server application.
Hi !
An additional subquestion: According to your experience, it seems that remotable client can't function without proxy DLL, which is in fact remotable server or sort of its modifocation (implementation etc). For someone who has DCOM experience it looks me a liitle odd, since DCOM proxy whas never real object, but just a thin layer for marshalling purposes. Moreover, when you restrict yourself for OLE automation types, you had already the windows default proxy & stub. As Jip drom Paris mentioned, there is really issue of intelectual property, because I am not interested to supply the remotable assebly with my client. Why do we have to make those tricks in order not to avoid supplying real assembly and MS don't propose some more elegant solution ? Thanks [quoted text, click to view] "Jip from Paris" <jipfromparis@hotmail.com> wrote in message news:<eCtT9D6bDHA.1488@TK2MSFTNGP12.phx.gbl>...
> "Mike Sheely" <honcho@microag.com> wrote in message > news:00e701c36f34$ebe5e300$a601280a@phx.gbl... > > > > -----Original Message----- from Jean Stax removed for brevity > > > > > You could, feasably build two different dlls, where the > > one that the client uses merely has empty (do nothing) > > functions (for the public methods). However, be careful > > if you do this. Only the public members of a class are > > remoted!!! Therefore, any non-public member functions you > > may have written actually run from the client's copy (the > > proxy) of the class that is loaded into the client's > > memory space (and non-public data members will also be > > found in the proxy, not at the server). The clients proxy > > for this remote object will actually contain all non- > > public member method implementations and the non-public > > member data. > > > > Let's take a sample to show how wierd this can get. We > > develop a remotable class that has a private method that > > changes a public data member. We deploy this class in a > > dll that both the client and the server apps will have > > available on their machines. Next, the client app creates > > an instance of our class (a proxy in the client's memory > > space) and calls our private method in that class. > > How can you invoke a method from outside an object if this method is private > ? > > > The private method will execute at the client machine (because > > it is going to run in the proxy). When it gets to the > > instruction that assigns a value to the public data > > member, this private method will make use of the proxy to > > make that assignment at the server's instance of the > > remotable object, because that data member was public (and > > therefore part of the server's instance of our remotable > > class). It can get a lot stranger if you begin to think > > about it. > > > > Stick tightly to the KISS Principle (Keep It Simple > > Stupid). The purpose of writing software is to simplify > > complex operations. Often times, we programmers will make > > such a complex solution (being cute) that our solution is > > worse than the original problem. > > > > Unless memory at the client machine is a problem, I cannot > > imagine why a person would build two different versions of > > a dll. I am sure there are other reasons than just > > limited memory that may be cause for consideration. > > However, maintaining two parallel projects and keeping > > changes synchronized in both would be a headache I would > > not want, unless it was proved to be absolutely necessary. > > > > I hope this helps, > > SheelyCritter > > I'm hard at trying to understand. At first place you say that deploying the > original assembly on the client with private methods might lead to strange > behavior under certain circumstances. This looks like advocating to deploy a > "special" assembly with those private methods trimmed out. Next, you call > for applying the KISS principle which I understand to promote the exact > opposite attitude !!! > > In several projects I have been working on, we decided to deploy a "special" > assembly. One of the reason is we didn't want to release the body of the > private methods for both IP and security reasons. Howevere, we were also > concerned about simplicity and robustness. The way we decided to handle it > was through Visual Studio project. Here is how we did under VS .Net. > > Project 1 is the server side assembly. Let's say we have the Remotable.cs > file in it. > > Project 2 is the client side version of the library produced by Project 1. > In project 2 we don't create any file but reference files from Project 1 > using the Add / Add Existing Item ... and choosing the "Link File" option > under the "Open" button. > > Next we modified the "Assembly Name" property in "Common Properties" / > "General" panel in Project 2 and gave the same name than the one in Project > 1. > > Next we added a "TRIM_OUT" conditional compilation constant in the > "Conditional Compilation Constants" property from the "Configuration > Properties" / "Build" panel in Project 2. > > We also modified each method in Project 1 so that it looks like > > public void Method() > { > #if (TRIM_OUT) > #else > // Real body for Project 1 only. > #endif > return; > } > > For methods returning an object reference, we have : > > public object Method() > { > #if (TRIM_OUT) > return null; > #else > // Real body for Project 1 only. > return result; > #endif > } > > The source code of every private and protected method in the source file is > also wrapped into the following conditional compilation directive : > > #if (!TRIM_OUT) > private void Method() > { > ... > } > #endif > > Now we add a reference to Project 2 in client application and a reference to
Hi Jean,
The way I use in my projects is to define a set of interfaces in a common assembly, say interface.dll, and reference/distribute it with both client and server assemblies. The implementation can be on the server, and the client simply uses the functions exposed through the interface. Here is a simple example // in interface.dll interface IFoo { void doIt(); } // in server public class Foo : MarshalByRefObject, IFoo { public void doIt() { // do something } } // in client IFoo obj = (IFoo)Activator.GetObject(typeof(IFoo), ServerUrl); obj.doIt(); obj in this case is just a proxy. Here I assume that Foo is a SAO so I use Activator.GetObject(), but you can also use Activator.CreateInstance() for CAOs. There is no problem for doIt() to call other private methods either way since Foo always runs on the server. HTH, Donald Xie [quoted text, click to view] >-----Original Message-----
>Hi ! >An additional subquestion: >According to your experience, it seems that remotable client can't >function without proxy DLL, which is in fact remotable server or sort >of its modifocation (implementation etc). For someone who has DCOM >experience it looks me a liitle odd, since DCOM proxy whas never real >object, but just a thin layer for marshalling purposes. Moreover, >when you restrict yourself for OLE automation types, you had already >the windows default proxy & stub. As Jip drom Paris mentioned, there >is really issue of intelectual property, because I am not interested >to supply the remotable assebly with my client. >Why do we have to make those tricks in order not to avoid supplying >real assembly and MS don't propose some more elegant solution ? > >Thanks > >"Jip from Paris" <jipfromparis@hotmail.com> wrote in message news:<eCtT9D6bDHA.1488@TK2MSFTNGP12.phx.gbl>... >> "Mike Sheely" <honcho@microag.com> wrote in message >> news:00e701c36f34$ebe5e300$a601280a@phx.gbl... >> > >> >> -----Original Message----- from Jean Stax removed for brevity >> >> > >> > You could, feasably build two different dlls, where the >> > one that the client uses merely has empty (do nothing) >> > functions (for the public methods). However, be careful >> > if you do this. Only the public members of a class are >> > remoted!!! Therefore, any non-public member functions you >> > may have written actually run from the client's copy (the >> > proxy) of the class that is loaded into the client's >> > memory space (and non-public data members will also be >> > found in the proxy, not at the server). The clients proxy >> > for this remote object will actually contain all non- >> > public member method implementations and the non- public >> > member data. >> > >> > Let's take a sample to show how wierd this can get. We >> > develop a remotable class that has a private method that >> > changes a public data member. We deploy this class in a >> > dll that both the client and the server apps will have >> > available on their machines. Next, the client app creates >> > an instance of our class (a proxy in the client's memory >> > space) and calls our private method in that class. >> >> How can you invoke a method from outside an object if this method is private >> ? >> >> > The private method will execute at the client machine (because >> > it is going to run in the proxy). When it gets to the >> > instruction that assigns a value to the public data >> > member, this private method will make use of the proxy to >> > make that assignment at the server's instance of the >> > remotable object, because that data member was public (and >> > therefore part of the server's instance of our remotable >> > class). It can get a lot stranger if you begin to think >> > about it. >> > >> > Stick tightly to the KISS Principle (Keep It Simple >> > Stupid). The purpose of writing software is to simplify >> > complex operations. Often times, we programmers will make >> > such a complex solution (being cute) that our solution is >> > worse than the original problem. >> > >> > Unless memory at the client machine is a problem, I cannot >> > imagine why a person would build two different versions of >> > a dll. I am sure there are other reasons than just >> > limited memory that may be cause for consideration. >> > However, maintaining two parallel projects and keeping >> > changes synchronized in both would be a headache I would >> > not want, unless it was proved to be absolutely necessary. >> > >> > I hope this helps, >> > SheelyCritter >> >> I'm hard at trying to understand. At first place you say that deploying the >> original assembly on the client with private methods might lead to strange >> behavior under certain circumstances. This looks like advocating to deploy a >> "special" assembly with those private methods trimmed out. Next, you call >> for applying the KISS principle which I understand to promote the exact >> opposite attitude !!! >> >> In several projects I have been working on, we decided to deploy a "special" >> assembly. One of the reason is we didn't want to release the body of the >> private methods for both IP and security reasons. Howevere, we were also >> concerned about simplicity and robustness. The way we decided to handle it >> was through Visual Studio project. Here is how we did under VS .Net. >> >> Project 1 is the server side assembly. Let's say we have the Remotable.cs >> file in it. >> >> Project 2 is the client side version of the library produced by Project 1. >> In project 2 we don't create any file but reference files from Project 1 >> using the Add / Add Existing Item ... and choosing the "Link File" option >> under the "Open" button. >> >> Next we modified the "Assembly Name" property in "Common Properties" / >> "General" panel in Project 2 and gave the same name than the one in Project >> 1. >> >> Next we added a "TRIM_OUT" conditional compilation constant in the >> "Conditional Compilation Constants" property from the "Configuration >> Properties" / "Build" panel in Project 2. >> >> We also modified each method in Project 1 so that it looks like >> >> public void Method() >> { >> #if (TRIM_OUT) >> #else >> // Real body for Project 1 only. >> #endif >> return; >> } >> >> For methods returning an object reference, we have : >> >> public object Method() >> { >> #if (TRIM_OUT) >> return null; >> #else >> // Real body for Project 1 only. >> return result; >> #endif >> } >> >> The source code of every private and protected method in the source file is >> also wrapped into the following conditional compilation directive : >> >> #if (!TRIM_OUT) >> private void Method() >> { >> ... >> } >> #endif >>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |