C
CSharpner
I have a click-once deployed application that I need to change which
web services it references *AFTER* deployment. When I change my
deployed xxxxxx.config.deploy file on the server so that it references
a different set of web services, the application continues to access
the old webservices.
Before you think you have the answer, let me tell you what I've done
(this has been a problem for about a year now, but we're determined to
get it resolved):
I manually edited the .config.deploy file to change the URLs of the
web services (original deployment pointed to a dev instance of the web
services), I'm changing them to point to the testing/staging
environment web services, then will change to point to production as
the compiled deployment moves it's way torwards acceptance and finally
production.
When I edited the file, I expected the app to refuse to run, but it
didn't. It ran without complaining (unlike what happens if I edit
the .application file without re-signing it). I even removed
the .config.deploy file and still no complaints and still it used the
dev web services.
Yes, I re-signed the manifest with mageui.exe. I edited
the .cong.deploy file, but it appears the app is not using
the .config.deploy file at all. In the source code, there's a
Settings.Designer.cs file that's generated based on my app.config and
in there is hard-coded the values of the web service URLs as they are
at the time of publish from Visual Studio to the development server.
Our deployment process has always been with web apps and this is new
territory for us (in spite of the fact that this app has been around
for about a year now... it's still our first one and has recently gone
to production). Our deployment procedures are as follows:
1. Compile and then the developer deploys to dev. then developer asks
admins to move it to staging (having admins changing the connection
strings and such in the web.config file). Developers don't have write
access to the staging envrionment.
2. Testers test application in the staging environment. If all goes
well, developer asks admins to move app from staging to production,
again making necessary changes to the web.config file. Developers
don't have access to the production environment.
On subsequent updates, the web.config file is just not copied, unless
there's anything new in it, then the admins are asked to add the new
items to the existing web.config files in each environment.
This process has worked well since the 1990's, but now with click-once
deployed apps, that procedure isn't working because we can't find a
way to make changes to the .config.deploy file without having to
publish from Visual Studio 3 seperate times, making the changes from
within Visual Studio for each environment. In addition, we can't move
a single deployment from environment to environment. We have to make
3 seperate builds, making it impossible to prove that what went to
production was truly what was tested.
Any help would be GREATLY appreciated!!!
web services it references *AFTER* deployment. When I change my
deployed xxxxxx.config.deploy file on the server so that it references
a different set of web services, the application continues to access
the old webservices.
Before you think you have the answer, let me tell you what I've done
(this has been a problem for about a year now, but we're determined to
get it resolved):
I manually edited the .config.deploy file to change the URLs of the
web services (original deployment pointed to a dev instance of the web
services), I'm changing them to point to the testing/staging
environment web services, then will change to point to production as
the compiled deployment moves it's way torwards acceptance and finally
production.
When I edited the file, I expected the app to refuse to run, but it
didn't. It ran without complaining (unlike what happens if I edit
the .application file without re-signing it). I even removed
the .config.deploy file and still no complaints and still it used the
dev web services.
Yes, I re-signed the manifest with mageui.exe. I edited
the .cong.deploy file, but it appears the app is not using
the .config.deploy file at all. In the source code, there's a
Settings.Designer.cs file that's generated based on my app.config and
in there is hard-coded the values of the web service URLs as they are
at the time of publish from Visual Studio to the development server.
Our deployment process has always been with web apps and this is new
territory for us (in spite of the fact that this app has been around
for about a year now... it's still our first one and has recently gone
to production). Our deployment procedures are as follows:
1. Compile and then the developer deploys to dev. then developer asks
admins to move it to staging (having admins changing the connection
strings and such in the web.config file). Developers don't have write
access to the staging envrionment.
2. Testers test application in the staging environment. If all goes
well, developer asks admins to move app from staging to production,
again making necessary changes to the web.config file. Developers
don't have access to the production environment.
On subsequent updates, the web.config file is just not copied, unless
there's anything new in it, then the admins are asked to add the new
items to the existing web.config files in each environment.
This process has worked well since the 1990's, but now with click-once
deployed apps, that procedure isn't working because we can't find a
way to make changes to the .config.deploy file without having to
publish from Visual Studio 3 seperate times, making the changes from
within Visual Studio for each environment. In addition, we can't move
a single deployment from environment to environment. We have to make
3 seperate builds, making it impossible to prove that what went to
production was truly what was tested.
Any help would be GREATLY appreciated!!!