|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Application changes propagating through the systemnoticable 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" <mach2@newsgroup.nospam> wrote in message What kind of application are you talking about? How is it deployed?news:2565778D-C182-45C1-A160-72B7E133B85A@microsoft.com... > 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? -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. 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 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. Show quote "NormD" wrote: > 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? Hi NormD,
> 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. 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 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? Show quote "Linda Liu [MSFT]" wrote: > Hi NormD, > > > 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. > > 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 > 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 > > > > 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? Show quote "Linda Liu [MSFT]" wrote: > 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 > > 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. Show quote "Linda Liu [MSFT]" wrote: > 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 > > > 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. Show quote "Linda Liu [MSFT]" wrote: > 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 > > 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  |
|||||||||||||||||||||||
Other interesting topics