By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,207 Members | 1,065 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,207 IT Pros & Developers. It's quick & easy.

What are the Consequences of Aspx page separate DLL from application DLL ?

P: n/a
Title: What are the Consequences of Aspx page separate from app DLL
Hi JL;
I am working on a big asp.net application.
When we migrate the dll (or dlls) to the production server, all users
who are login into the application are pumped off. In fact we must
close down the server (to preserve users from being logged on and
thinking they are updating data when it is in fact lost when we move
the dlls to the the applications bin directory).
What can be the reason for this? I checked to the "Temporary ASP.NET
Files" library and there does seem to be shodow copying going on of my
applications DLL.

One thing that might have to do with this is that the aspx pages are
NOT part of my Application DLL, that contains all the code that drives
and displays the pages (in *.cs files). The Dll is called
XXCSDLIB.dll

The file login.aspx:

<%@ Page language="c#" %>
<%@ Import Namespace="XXCSDLIB.Pages" %>
<script runat=server language="c#">
XXCSDLIB.Pages.login pageObject;

private void Page_Load(object sender, System.EventArgs e) {
pageObject = new XXCSDLIB.Pages.login();
}
</script>

<% pageObject.DoPage(Context); %>

There are no @Page Directive Attributes such as Inherits.
And my aspx page is not a project or part of my Visual Studio Solution
library.

My aspx page becomes an instance of its own class, ASP.login_aspx,
that inherits from the Page class (as I understand it). On Page_Load
in makes an XXCSDLIB.Pages.login object and then calls the
login.DoPage(HttpContext) method. The XXCSDLIB.Pages.login class is
from the login.cs file that is compiled into the XXCSDLIB.dll linked
library.
So I don't think I want the @Page Directive Attribute "src" because
there is no codebehind page.

According to the login.aspx page that is rendered as XML in the
shadowed copied library (see below). MY login.aspx is in a completely
different assembly than XXCSDLIB.dll, called "9vjm3ycg", so when I use
the ASP.login_aspx and then xcopy the XXCSDLIB.dll, the in process
link between the two is destroyed. This is how it is with all my aspx
pages.

Why is that? Is it because the aspx dlls and the application dll share
complete different sessionstates? Does it have anything with this to
do?

Jesse, your or others that might know, comments to my question and in
fact the entire scenario is very wellcome!

Regards,
Paul

In the temp shadowed copy library my login.aspx is better known as an
XML file, login.aspx.2b58a.xml. It looks like this.
<preserve assem="9vjm3ycg" type="ASP.login_aspx"
hash="ff6d03f98fbe092e">
<filedep name="C:\Inetpub\wwwroot_8007_paul\bin\XXCSDLIB.DL L" />
<filedep name="C:\Inetpub\wwwroot_8007_paul\login.aspx" />
</preserve>
Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Please note that newsgroups that don't include dotnet have nothing to do
with the .NET framework & thus you shouldn't be posting questions about
it there. You did post to a .net newsgroup so maybe they can help you.

Paul wrote:
Title: What are the Consequences of Aspx page separate from app DLL
Hi JL;
I am working on a big asp.net application.
When we migrate the dll (or dlls) to the production server, all users
who are login into the application are pumped off. In fact we must
close down the server (to preserve users from being logged on and
thinking they are updating data when it is in fact lost when we move
the dlls to the the applications bin directory).
What can be the reason for this? I checked to the "Temporary ASP.NET
Files" library and there does seem to be shodow copying going on of my
applications DLL.

One thing that might have to do with this is that the aspx pages are
NOT part of my Application DLL, that contains all the code that drives
and displays the pages (in *.cs files). The Dll is called
XXCSDLIB.dll

The file login.aspx:

<%@ Page language="c#" %>
<%@ Import Namespace="XXCSDLIB.Pages" %>
<script runat=server language="c#">
XXCSDLIB.Pages.login pageObject;

private void Page_Load(object sender, System.EventArgs e) {
pageObject = new XXCSDLIB.Pages.login();
}
</script>

<% pageObject.DoPage(Context); %>

There are no @Page Directive Attributes such as Inherits.
And my aspx page is not a project or part of my Visual Studio Solution
library.

My aspx page becomes an instance of its own class, ASP.login_aspx,
that inherits from the Page class (as I understand it). On Page_Load
in makes an XXCSDLIB.Pages.login object and then calls the
login.DoPage(HttpContext) method. The XXCSDLIB.Pages.login class is
from the login.cs file that is compiled into the XXCSDLIB.dll linked
library.
So I don't think I want the @Page Directive Attribute "src" because
there is no codebehind page.

According to the login.aspx page that is rendered as XML in the
shadowed copied library (see below). MY login.aspx is in a completely
different assembly than XXCSDLIB.dll, called "9vjm3ycg", so when I use
the ASP.login_aspx and then xcopy the XXCSDLIB.dll, the in process
link between the two is destroyed. This is how it is with all my aspx
pages.

Why is that? Is it because the aspx dlls and the application dll share
complete different sessionstates? Does it have anything with this to
do?

Jesse, your or others that might know, comments to my question and in
fact the entire scenario is very wellcome!

Regards,
Paul

In the temp shadowed copy library my login.aspx is better known as an
XML file, login.aspx.2b58a.xml. It looks like this.
<preserve assem="9vjm3ycg" type="ASP.login_aspx"
hash="ff6d03f98fbe092e">
<filedep name="C:\Inetpub\wwwroot_8007_paul\bin\XXCSDLIB.DL L" />
<filedep name="C:\Inetpub\wwwroot_8007_paul\login.aspx" />
</preserve>


Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.