Re: Deployment + Vista

I'm guessing something didn't get cut and pasted into that reply, cuz you
lost me with the early part of your reply.

But interestingly enough, this past week I had to deploy an app onto a small
network. A few days later one of the offices had a new Vista installation.
Within a matter of minutes, I had XCopied the app and the server.xml and
server.xds files into a directory, fixed an unrelated network connectivity
issue (the server is on a different machine), and we were off and running.
Have had absolutely no problems with the Vista machine at all in the
scenario I described to you.

I'm not a big fan of using the app.config file to handle my server settings.
It's been a few years since I quit trying to use the app.config file for
that purpose, mainly because I wanted a more control over the file and file
structure that was being handled in order to save and retrieve those
settings.

I'm not sure how "Vista will temp your changes" because these are being
hard-written into the "server.xml" file (NOT the app.config file). Indeed it
seems to me that this is exactly the scenario where a file that Microsoft
does not control would be a better solution.

"Steven Spencer (Spinalogic)" <Spence-Spinalogic@xxxxxxxxxxxxxxxx> wrote in
message news:OlXlbZFaHHA.5080@xxxxxxxxxxxxxxxxxxxxxxx
Your description vista wise just fell over at "(into the app directory),
then give the user an input
panel so that they can specify any changes" Vista will temp your changes
to the app directory and then discard them upon exiting the form.

Secondly:
Then I can call a GetConnectionString() function that calls the retrieval
function in order to put together the connection string something like:
m_strConnection = "data source=" + m_strSQLServerName + ";initial
catalog=" + m_strDatabaseName + ";integrated security=SSPI;"

I'm well aware of this pattern, and it is in fact the one I was using
previous to discovering the app.config setting.

My only problem with it is it is error prone for a multi developer
environment, if someone updates the data layer they may forget that call
and the app will look like it works fine in testing until we deploy...

I guess my question was exactly what I said: Is there a way at design time
to tell the sqldataadapters where to get its connection string from? OR a
way of using an application setting that is actually writeable at runtime.


Either way, I do not wish to have to have to change the setting during
"Earl" <brikshoe@xxxxxxxxxxxxxxxxx> wrote in message
news:u0AtES6YHHA.1580@xxxxxxxxxxxxxxxxxxxxxxx
I know nothing about Vista, but you do not have to bind your connection
string to your strongly typed datasets.

In the display layer of the app, I keep the strongly-typed datasets
empty, then when I need data, I call .Merge() on the strongly typed
datasets in order to return datatables from the appropriate data layer
classes. Within those classes is where I open dynamically created
connections.

I deploy a small .xml and .xsd file with the default server name and
database settings (into the app directory), then give the user an input
panel so that they can specify any changes. Separately, I create a class
with separate functions to save and retrieve the settings, and with a
couple of properties for the server and database name. Then I can call a
GetConnectionString() function that calls the retrieval function in order
to put together the connection string something like: m_strConnection =
"data source=" + m_strSQLServerName + ";initial catalog=" +
m_strDatabaseName + ";integrated security=SSPI;"

As you can see, the only hard-coded aspect of the string is simply the
security. If necessary, you could even modify that, although if you are
deploying with SqlExpress, you already know what the security setting
will be.

"Steven Spencer (Spinalogic)" <Spence-Spinalogic@xxxxxxxxxxxxxxxx> wrote
in message news:eqTquLrYHHA.984@xxxxxxxxxxxxxxxxxxxxxxx
We use strongly typed datasets, and thus our connection string is bound
to an application setting.

Currently we can deploy and alter the app.exe.config file at
installation time to successfully install, and use some basic XML
editing to allow the target database to be changed.

Writing to the application directory in vista will throw compatibility
errors, and not persist the changes at all.

What do we do? Is there a better way of getting the connection string
in your application, or a way of telling the designer where to get your
connection setting from??







.

Relevant Pages

  • Re: Deployment + Vista
    ... The problem is it's connection string is always ... Server settings form. ... possibly occur with a file created by your app. ... I guess it's a good thing I do not use that for settings. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Deployment + Vista
    ... The problem is it's connection string is always ... Server settings form. ... possibly occur with a file created by your app. ... I guess it's a good thing I do not use that for settings. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Calling Sql Server 2000 from C# Express
    ... Instead of hard coding your connection string, ... from a config file for your app? ... don't have to worry about re-compiling your app anytime you want to specify ... a different server. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Deployment + Vista
    ... I'm talking about the user being able to edit the server connection setting ... MSI will allow you to edit the app directory, ... function in order to put together the connection string something like: ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Crystal Reports, CrystalDecisions.ReportSource
    ... you have to do more than simply copy the app directory to the web server, ...
    (microsoft.public.dotnet.languages.csharp)