Strange situation ---how is this happening?

[Hannibal111111]

I am getting a strange situation with a .NET 1.1 web application that
we have deployed. I have made an update to a code behind page in 1
file, and then made an update to another code behind page. After that
I rebuilt everything. This is all on my dev server. Now I move the 1
code behind page and the updated dll to the live server. But I did not
move the other code behind page to the live server. Now somehow I am
getting an error on the live server that is referring to the updated
code behind page that has NOT been moved to the live server. How is
this possible? How can it error out on code that hasn't been made live
yet?

Thanks,

Chris Green

 

[Nick Malik [Microsoft]]

As you know, your code behinds are compiled, not script like they were in
ASP. What you might not know: they are normally all compiled into one DLL.
So if you update the code-behind pages for two pages on the same site, and
compile, and deploy the dll, you've deployed both changes.

That is intentional.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Hannibal111111]

As you know, your code behinds are compiled, not script like they were in
ASP. What you might not know: they are normally all compiled into one DLL.
So if you update the code-behind pages for two pages on the same site, and
compile, and deploy the dll, you've deployed both changes.

That is intentional.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

So even if I don't move the code-behind page to the live server,
because I have updated the dll it will still run the updated code from
the code-behind page? Is the code stored in the dll? How do I prevent
the new code from running if I don't want it to but have to update the
dll because of a bug fix somewhere else on the site?

Chris

 

[Nick Malik [Microsoft]]

Our messages are a bit out of order, so I reordered the text of the
conversation to make it easier for me.

So even if I don't move the code-behind page to the live server,
because I have updated the dll it will still run the updated code from
the code-behind page?

I'm not sure if I'm understanding correctly. I assume you mean this:
You created a new ASPX page.
The code behind needed a different feature from existing code
You modified existing code to provide this new feature. This work is not
complete.
You also had to fix a bug in existing code. You did so. This work is
complete.
You deployed the bug fix.
Even though the ASPX page itself is not deployed, you are confused as to why
the feature change went into production.

By definition, you have two things here: you have the ASPX page (which is
now fairly light, unless you are in the Ajax model) and you have the
code-behind, which is a shared DLL for the entire site.

You have a classic problem: two bodies of code, one for supporting existing
functionality, while the other is for rolling out new functionality.

There are lots of different ways to work around this, but the most common
are:
1) branch your source control tree to allow bug fixes in one body of code
while allowing new features to be added to the other. Note that bug fixes
have to be made in both branches. This often means making the same
functional change twice.
2) create new classes in your code that the new features will use, and
maintain both the old classes and new classes. Roll out as often as you
want, as long as the new classes are not called. On the date for rolling out
the new feature, either statically (through redeploy) or dynamically
(through logic) the system will call the new classes instead of the old
ones. At some point, remove the old classes from the code and redeploy.

They are variations on the same theme.

I assume you have either VSS or VSTS?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Hannibal111111]

Our messages are a bit out of order, so I reordered the text of the
conversation to make it easier for me.


I'm not sure if I'm understanding correctly. I assume you mean this:
You created a new ASPX page.
The code behind needed a different feature from existing code
You modified existing code to provide this new feature. This work is not
complete.
You also had to fix a bug in existing code. You did so. This work is
complete.
You deployed the bug fix.
Even though the ASPX page itself is not deployed, you are confused as to why
the feature change went into production.

By definition, you have two things here: you have the ASPX page (which is
now fairly light, unless you are in the Ajax model) and you have the
code-behind, which is a shared DLL for the entire site.

You have a classic problem: two bodies of code, one for supporting existing
functionality, while the other is for rolling out new functionality.

There are lots of different ways to work around this, but the most common
are:
1) branch your source control tree to allow bug fixes in one body of code
while allowing new features to be added to the other. Note that bug fixes
have to be made in both branches. This often means making the same
functional change twice.
2) create new classes in your code that the new features will use, and
maintain both the old classes and new classes. Roll out as often as you
want, as long as the new classes are not called. On the date for rolling out
the new feature, either statically (through redeploy) or dynamically
(through logic) the system will call the new classes instead of the old
ones. At some point, remove the old classes from the code and redeploy.

They are variations on the same theme.

I assume you have either VSS or VSTS?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

So would I just comment out the calling of the new classes (with the
new functinality) until such time as they are needed?

Thanks,

Chris

 

[Hannibal111111]

Our messages are a bit out of order, so I reordered the text of the
conversation to make it easier for me.


I'm not sure if I'm understanding correctly. I assume you mean this:
You created a new ASPX page.
The code behind needed a different feature from existing code
You modified existing code to provide this new feature. This work is not
complete.
You also had to fix a bug in existing code. You did so. This work is
complete.
You deployed the bug fix.
Even though the ASPX page itself is not deployed, you are confused as to why
the feature change went into production.

By definition, you have two things here: you have the ASPX page (which is
now fairly light, unless you are in the Ajax model) and you have the
code-behind, which is a shared DLL for the entire site.

You have a classic problem: two bodies of code, one for supporting existing
functionality, while the other is for rolling out new functionality.

There are lots of different ways to work around this, but the most common
are:
1) branch your source control tree to allow bug fixes in one body of code
while allowing new features to be added to the other. Note that bug fixes
have to be made in both branches. This often means making the same
functional change twice.
2) create new classes in your code that the new features will use, and
maintain both the old classes and new classes. Roll out as often as you
want, as long as the new classes are not called. On the date for rolling out
the new feature, either statically (through redeploy) or dynamically
(through logic) the system will call the new classes instead of the old
ones. At some point, remove the old classes from the code and redeploy.

They are variations on the same theme.

I assume you have either VSS or VSTS?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

So would I just comment out the calling of the new classes (with the
new functinality) until such time as they are needed?

Thanks,

Chris

 

[Nick Malik [Microsoft]]

Nick Malik [Microsoft] wrote:

So would I just comment out the calling of the new classes (with the
new functinality) until such time as they are needed?

Thanks,

Chris

That would be one interpretation of my second suggestion above. Yes. Just
comment out the calls to the new code, recompile, test, and deploy.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--