I have a fairly straightforward problem that I imagine has a simple solution. However, it's not clear to me. Here's the problem:
I have a web application that references a class library. That class library needs to access the connection strings in the web.config. From what I've read, this shouldn't be a problem.
Here's the code that I'm using to access the connection strings:
Dim connectionStrings As ConnectionStringSettingsCollection = ConfigurationManager.ConnectionStrings
When I run this code in the web application, I get all of my connection strings back. However, when this exact same code is run in the class library (called from the web application), it reverts to the machine.config for some reason and gets the entry from there. i.e.
data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
I'm not sure if it matters or not, but the web side of this is a WCF RIA services web site that backs a Silverlight application. I didn't see anything funny in the config that could justify this strange behavior. Any thoughts on why I'm seeing this behavior?
Thanks,
Matt
There's a "WebConfigurationManager" Class, I guess it may solve your problem.
Related
I currently have an ASP.NET website that has an encrypted connection string within it's web.config file. The settings are in the general AppSettings section, not the ConnectionString section. Within the application code we manually decrypt the connection string at run time as needed.
While working on refactoring the site, I came across a method that Microsoft once suggested which involves running an aspnet_regiis command in order to insert encrypted data directly into the ConnectionString section of the web.config file. This suggested method is now considered Retired Content although it doesn't say why (other than a small reference that some of the links may no longer be valid).
Here's the site I'm referring to:
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
My questions are basically - Should I bother refactoring the existing functionality to use Microsoft's once recommended way? I believe it would be more efficient than the current process. Also, why would this method be considered Retired Content? Is there a better way to do this, rather than my site supporting the encrypt/decrypt methods?
I've search Google & StackOverflow for other ways of doing this, but they all seem refer to Microsoft's way - or the way I currently have it implemented.
Maybe the site/doc you're referring to is marked as obsolete, but the technology behind is not. Here are the official links, not marked as obsolete:
DpapiProtectedConfigurationProvider Class (with an example), there is also the RsaProtectedConfigurationProvider that is capable of encrypting sections
Encrypting Configuration Information Using Protected Configuration
Encrypting and Decrypting Configuration Sections
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) with the -pe option
I would definitely use this technology.
I'm guessing that they say the documentation is considered retired content because it was written for the .NET 2.0 framework. That being said, as Simon said, the technology behind it is still good to use.
The nice thing about using aspnet_regiis to encrypt your web.config file is that it is transparent to the application. You can write your logic assuming that the appSettings or connectionStrings sections are not encrypted, and if they are are encrypted using this method the .NET framework will take care of decrypting them before giving you the value.
One thing to keep in mind with using this method is that it will encrypt the entire appSettings section. If you open your web.config once it's encrypted you will not see any of the keys, but just a big encrypted hunk of data.
I have a client that wants to wrap the provider model with a middleware library, thereby keeping all Security.Web namespaces and API calls out of the front end completely.
Setting up calls into the API is easy. But configuring an app.config file is not quite as intuitive. I've not been able to find a good example.
What's the proper way to setup an app.config file for ASP.NET provider model use from outside a web project?
I was missing the <system.web> tag to be wrapped around the provider information. DOH!
Everything works like a charm now. Sorry for the snipe hunt. ;)
Could anyone please explain why when creating a WCF webservice in which you want to use HttpContext.Current.Items you need to add some code in 2 places?
One in the webservice itself ([AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]) and one in the web.config file (<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />)?
A colleague of mine just had all his webservice calls failing. He had the web.config setup missing and asked me why. I tried to explain, but I'm not sure if I was able to :)
I think it has to do with the separation of the webservice code and the place where the webservice gets hosted. The webservice itself says that it needs that compatibility mode. It is then also needed to setup the hosting environment to say that it should run in that compatibility mode.
Isn't this basically the point?
He still had a question: "but, if the service uses that attribute, should it not be automaticly ?"
The first tells WCF that aspcompat must be enabled and the second enables it. You should be able to do without the first.
This forces the person configuring the WCF service to use the right config.
MS designed this with the idea that the person configuring the service might be someone else that the person that made it.
To answer his last question. When you add attributes to your service you're not configuring the host, you're demanding how the host should be configured. The configuring happens on the host.
I came across a case study few days early. It is related to a web application architecture.
Here is the scenario,
There is a single web service used by say 1000 web applications. This web service is hosted on a particular server. If web service hosting location is changed, how the other applications come to know about this change ?
Keeping it in web.config doesn't seems to be a feasible solution as we need to modify web.config files for all the applications.
Keeping these settings in a common repository and let all the applications use it for web-service address was came in my mind, but again there is a question of storing this common repository.
I am just curious to know about how this could be achieved with better performance.
Thanks in advance for any kind of suggestions.
do you have full access or control over all those web applications consuming that web service? if so, you could have a script or some custom code which updates all their web.config(s) at once. it seems too much work but in fact in this way you have more control and you could also, eventually, point to the new url only some applications and leave some others on another url.
the idea with the setting in a centralized database gives you faster update propagation which could also be bad in case of errors and then you have all applications referring to the same place and no way to split this. Then you have anyway to connect to a centralized database from all of them and maybe you should add a key to their web.config(s) with the connection string to that database, then, in case that database is not reachable or is down, the web applications will not be able to consume the web service simply because they cannot get the url of it.
I would go for the web config, eventually you could have a settings helper class that abstract the retrieval of that url so the UI or front end does not know from where that url comes from.
anyway, do you plan to change the url of a web service often? wouldn't be better to copy it to a new url but to also keep it available on the current url for a while?
another advantage of web.config approach is that everytime you update and save it the application is restarted while a change in a database might take a while to be detected in case you have some caching mechanism,
hope this helps.
Davide.
I want to pass session from one application to other.
Like what gmail and orkut is doing, i want to do that.
Can anyone have some idea about how to do it?
Can it be possible without using any DB.
Assuming you want to control the entire pipeline - to accomplish this you need a centralized state server of some kind, which both sites can communicate with on the backend. For many smaller applications the database itself is used as a state server, but that is just one implementation of many. There are dedicated state server products, some free and some paid.
Even if both of your applications are on the same server, it's not possible with out-of-the-box ASP.NET functionality to share session directly because in-memory session is in process. However, running either of the two products listed above on the same physical machine as both your applications, and pointing both applications to that state server, will get you nearly there - it will be the same memory footprint as if they truly shared session, and the performance is extremely good (interprocess communication is blisteringly fast compared to network I/O).
Here is a more detailed description of the mechanics of a common authentication scheme between two or more sites.
What language are you using? If you are using ASP.NET on IIS, which I'd assume by your tags, you can do it using the machineKey attribute of <system.web> in the web.config file. It would look similar to this:
<system.web>
<machineKey validationKey="(here)" decryptionKey="(here)" validation="SHA1" />
</system.web>
Then, you can use the enableCrossAppRedirects="true" attribute on <forms> authentication type if you'd like the authentication keys to be passed between apps.
Also, if you'd like to generate a machineKey, you can use Scott Forsyth's tool at http://www.orcsweb.com/articles/aspnetmachinekey.aspx
Finally, as the first answer was posted, you can implement the ASP.NET state server for better control of the application's state. The ASP.NET team will be releasing Velocity soon which handles distributed caching. There are also third party tools for both.