Application changes propagating through the system

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We've had several instances where changes made in a system seem to take
noticable time to propagate through the system. Is this normal? Is there a
way to force things to happen?

In one case the developer modified the configuration file on the server.
She cleared the GAC on her machine and re-ran the application that referenced
the config file. the app "saw" the old file; it acted as if the old version
was still cached somewhere.

We've installed new versions of programs on the server and, again, when
someone runs the app they're not seeing the new stuff. Clearing the GAC
doesn't help.

In several cases a problem of "seeing" new files seemed to resolve itself
over, say, the weekend; this has happened with several customer's systems, so
it isn' just something one is doing ot not doing.

Besides clearing the GAC on a cliend machine, is there something else that
can/should be done? What about on the application/Web Services server where
the program, config, form dll, web services, etc. sit? Does or should
something be done here to clean out any cache, etc. to make sure the new
version of something is what it actually used?
 
NormD said:
We've had several instances where changes made in a system seem to take
noticable time to propagate through the system. Is this normal? Is there
a
way to force things to happen?
Click to expand...

What kind of application are you talking about? How is it deployed?

-cd
 
Hi,

I am sorry that I may not understand your problem exactly.
In one case the developer modified the configuration file on the server.
Click to expand...
She cleared the GAC on her machine and re-ran the application that
referenced
the config file. the app "saw" the old file; it acted as if the old
version
was still cached somewhere.

What has been modified in the configuration file by the developer ? Does
she run the application on her machine? What the "old file" refers?
We've installed new versions of programs on the server and, again, when
Click to expand...
someone runs the app they're not seeing the new stuff.

What kind of the application you installed on the server? How the user runs
the application?

I look forward to your reply.


Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
1) the web config file sits on the application server along with all the EXE,
form DLL and other chunks of code. A user runs the EXE via a link on their
desktop. Programs, DLLs, etc. come down to the client machine, are cached in
the GAC as needed. There is no code stored on the clients.

One thing I mentioned was that changes made to the config file on the server
were not "seen" by the application when it was run again, even after clearing
out the GAC.

We (and customers at other sites) havev also had problems with new versions
of the code and form DLLs seemingly not being available when the files on the
application server are replaced. Again, even with cleaning out the GAC on
the client machines, it seems like it takes time (over a weekend?) before the
new files are used.

This is why I'm wondering if there is some other caching going on besides on
the desktops accessing the app server.

2) I don't know what you mena by "what kind of application." Besides what I
describer above, there is also a set of Web Services on the application
server that takk with a database. The client passes DBMS requests to the Web
Services, which talk with hte database, get data back from the DBMS, and pass
it to the client.
 
Hi NormD,
One thing I mentioned was that changes made to the config file on the
Click to expand...
server were not "seen" by the application when it was run again, even after
clearing out the GAC.

What would you like the application to do after you changed the config file
on the server? You may have a try running the program on the server to see
whether the program could "see" the changes made to the config file.

Well, since you have referred to EXE on the server definitely, the
application must be WinForms applicaiton.
This is why I'm wondering if there is some other caching going on besides
Click to expand...
on the desktops accessing the app server.

I am doing research on this question and will get back to you as soon as
possible. I appreciate your patience.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
Thank you for looking into these issues.

As far as what we waht it ti do after changing the config file, the real
answer is to use the changed config file! The specific act doesn't matter;
I'm not looking for another way to do somoething, just use the new config
file. Likewise when a form DLL is changed on the application server we want
the application to use the new form when run from the desktop.

As I've said before it acts like it takes time for these changes to make it
through the system even though we cleal the clients' GAC.

Do you know if there is also caching taking place on the application server
that we have to flush out?
 
Hi NormD,

I am sorry that I still have some questions about this issue.

Is the program on the application server a WinForms applicaiton? If so, I
think you should use a app config file rather than web config file.

What's more, if you change a dll file on the application server, you should
rebuild the application to use the new dll file and needn't change the
config file.

You have mentioned that the user runs the applicaiton via a link on his
desktop. Could you tell me what kind of the link is? Is it a url or
shortcut?

You may restart the application server to see if the problem still exist.

Hope this helps.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
It is a WinForms application. EXE, form DLLs, etc., are typically stored on
the app server and the client gets them as needed. It is using several
config files, actually. There is an "exe config" in the directory where the
exe file is, and a "web config" where the web services are.

The only thing running on the application server is web services that talk
to the client and DBMS (which could be on the same server or another one).

Changing a dll does not by any means always require a total rebuild of the
application; it depends on the dependenccies in the dll. If you want the GAC
to update the application version needs to be changed.

A shortcut on the client desktop can run an application as
//server/program.exe or via HTTP. Sow saying something is run by a shortcut
doesn't spell out how it is run.

The progrran CAN be run either way. I've been told that if run via
//servername/program.exe it does not get cached in the GAC, but that using
HTTP is is cached in the GAC.

Restarting an application server in a multi-national corporate environment
is not something cassually done. Point is, should this have to be done?
 
Hi NormD,

Thank you for your detailed update.

Based on my understanding, you have a WinForms applicaiton and a Web
Service on your Application Server. The WinForms applicaiton has a
application config file in its directory and the Web Service has a web
config file in its directory as well. The WinForms application interacts
with the Web Service to acess DataBase. The user runs the WinForms
application which is on the server on his client desktop using a UNC path
or HTTP.

Now you have two questions.
1. After you change the content in the application config file on the
server, the user restarts the WinForms application on his client desktop
but the application couldn't see the new content in the application config
file.

2. After you replace some of the dll files that the WinForms application
depends on the server, the user restarts the WinForms application on his
client desktop but the application doesn't use the new dll files.

As for the first question, are the dll files that the WinForms application
depends Strong-Named? If not, these assemblies won't be intalled to the
Global Assembly Cache on the client desktop when the user runs the
application on his client desktop.

If the user runs the WinForm application using UNC, the EXE, dll and
application config files won't be downloaded to the client desktop.

If the user runs the application using HTTP, the EXE, dll and application
config files will be downloaded and cached in the IE temporary folder.

As for the second question, I recommend you to run the WinForms application
on the Application Server to see if the application could use the new dll
files first. If yes and the user is using HTTP to run the application,
clear the IE temporary folder.

For you information, if you change the content in the web config file and
want the Web Service to see the new content, you should restart the
corresponding services of the WebService.

Hope this helps.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
Linda, thanks for reminding me that I needed to answer your latest message!
Got sidetracked.

Everything is strong named. And updates take this in to account.

The program typically can be run from the application server for test
purposes, as that takes the network and client machines out of the picture.
But regarding the question about whether these problems also exist when
running the application from the app server, I don't know. We can only try
to look for it the next time we encounter the situation.

Re installing a new dll on the app server and other changes on the app
server, is there not a way to "flush" the local caches, etc. without
restarting the server?

We're not aware of how to stop and restart a Web Service. I can see thatIIS
itself can be stopped and started (and we've had people do that at times) but
I don't see how to do this foe a specific Web Service under IIS. Can you
explain or point me to something that explains?

When you say files are not downloaded to the client when running the app via
UNC, don't you mean cached? If you run an app from a server it actually runs
on the client after loading from the server; Word or Excel, for example. The
files don't get cached but they do come doown to the client from the server.

Speaking of caching, it seems like when the application is run the files
come down as needed the first time and then the cache is used if you re-use,
say, a dll for a form (close the form trhen reopen it). We can see this
happening with network tract tools. But if the application is closed the
next time it is run (even just minutes later) everything has to come down
from the server again. What was in the cache is not reused.

Is this the way things are supposed to happen? Are there settings for it?
I was under the impression what's in the cache is reused. .NET checks for a
later version on the server, but if there isn't a newer version what's in the
cache gets used to save having to download over the net each and every time.
This is not what's happening. I wish it did; the network slows the initial
loading of each component even though it hasn't changed.
 
Hi NormD,

Thank you for your detailed feedback.

I performed a test as follows.
1. Set up a Windows Application and a Class Library projects on PC1.

2. Add a setting in the app.config file of the Windows Application project
and add code in the Windows application to read the value of the setting
from the app.config file.

3. Add a reference to the Class Library project in the Windows Application
project. Don't copy the assembly to local(To do this, right-click the
assembly under the Windows Application project's References node in
Solution Explorer and select Properties. Select False in the "Copy Local"
node.)

4. Sign the assembly of Class Library project, build the project and add
the assembly to the GAC on the PC1.

5. Build the Windows Application project.

6. Create a shortcut to the Windows application exe file using a UNC path
on PC2.

7. Double-click the shortcut to run the Windows application on PC2.

The result of my test is as follows.

1. When the program tries to use the strong-named assembly it refers, an
error occurs saying that "couldn't load the assembly file...". The assembly
that the Windows applicaion depends on isn't downloaded to the GAC on PC2.

2. The program could read the app.config sucessfully.

3. I use the File Monitor tool to see the startup paths of the Windows
application and app config file on PC2 and see that the Windows application
and app config file are all of UNC paths. So I could draw a conclusion
that the Windows application exe file and app config file aren't downloaded
to PC2 to run on it.

4.I also try to modify the app config file on PC1. The change isn't seen by
the Windows application running on PC2 immediately, but the Windows
application does see the change in the app config file when I start it on
PC2 again.

You have mentioned the assemblies that your Windows application refers are
all strong-named. Where do you put them on the server? Are they in the GAC
or the same path as the Windows application or both the above two places?

If the assemblies are only in GAC, you should move them to the GAC on the
client pc to make the Windows application run properly on it. When you
change the assemblies, you should update them in the GAC on the client pc
too.

If the assemblies are only in the same path as the Windows application, you
shoud update them in this path.

If the assambiles are in both the above two places, you could only update
them in the path that the application resides.

Note that if you have changed the versions of the assemblies, you should
rebuild the Windows application to ensure the application to refer to the
latest version of assemblies.

As for the feature that .NET checks for a later version on the server and
if there isn't a newer version, it will launch the program in the client
pc, it's only supported in the Smart Client program. This feature is not
supported in this scenario.

Finally, I would say sorry that I made a mistake in my previous message.
There's corresponding service for a WebService. To make the new web config
file take into effect, we should only restart the IIS service.

Hope this helps.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
Your test is interesting. Obvious question is "Why can't the assembly load?"
Likewise, why the app config file isn't seen correctly right away.

As I previously surmised, seems like there is some hidden caching going on.

If so, who do we force that clearing out when new stuff is posted on the
server? Stopping and starting IIS might be a "fix" but is a bit drastic,
IMHO.

Application on the server is just in directories. We do not load it into
the GAC.

Be advised that all parts of an application do not have to be rebuilt when
onoe changes. It depends on the dependencies.
 
Hi NormD,

I have consulted with my colleagues and performed a test about the question
whether the program is downloaded or cached to client pc when it is lauched
on the client pc using a UNC path.

In my test, I use File Monitor tool to see the startup paths of the
Windows application, assembly file that the Windows application refers and
the app config file. They're all of UNC path. After I modify the content in
the app config on the server and restart the program on the client pc, the
program see the new content in the app config.

This is not a complex scenario. As I have mentioned in my previous reply,
after you modify the app config file or the assembly file, you could
restart the Windows application on the server to see if the application
could see the new content in the app file and load the new assembly file.
If yes, you could restart the application on the client pc to take the same
check.

Hope this helps.


Sincerely,
Linda Liu
Microsoft Online Community Support
 
Back
Top