Re: Random DLLs and Web Hosting Services

On Fri, 2004-09-10 at 15:31, Siegfried Heintze wrote:
> >> Our hosting service uses software to detect whenever a new DLL is loaded
> on
> >> their system. It appears that ASP.NET copies my DLL into the temporary
> >> directory with some random file name. This makes our hosting service very
> >> upset because it looks like they are under attack whenever ASP.NET makes
> a
> >> DLL in the temporary directory.
> >>
> >>
> >
> >I don't think it is a copy of the Native C DLL.
> >An ASP.NET application
> >will create a new Assembly ( a .NET .DLL) whenever the code in your
> >application is changed.
>
>
> Ah hah! I'm not manually or explicitly compiling the C# code. I'm just using
> the auto-compilation feature which compiles the code when I first hit the
> page (or in this case, the service). If I was to explicitly compile the C#
> into a DLL on my local machine and copy the DLL (instead of the C# source
> code) to the hosting service, would this fix the problem?
>

Yes, it should do yes. You have to put the compiled DLL into the bin/
subdirectory of the application directory.  However that even if you
have no code in your .aspx (or .asmx) file, this will still be parsed
and turned into a .DLL everytime it is changed. This is done completely
automatically and I am not sure that you can intervene.  Best policy is
to put all of the code into a separate file that you can compile
separately though.

>
> >If you are P/Invoking functions from a Native
> >.DLL then the .NET framework uses the systems dynamic loading capability
> >to discover the location of the .DLL, load it and call the methods - so
> >in this respect is no different to a native application.
>
> No we are not.
>
> >The only other
> >occasion you may get a new .DLL that you didn't explicitly create is
> >when you are instantiating a COM object from a .NET application by
> >referencing it directly, in this case you will get an 'interop assembly'
> >that takes care of the loading and so forth and make it appear that you
> >are dealing with a .NET class, but this is not the case in your example.
> >
> No we are not.
--

This e-mail is sponsored by http://www.integration-house.com/