I have a multi-tiered ASP.Net MVC 3 application in which different layers need to share some settings, and I am wondering how to best achieve this.
For now, all my AppSettings are in the Web.config file, but I just added a new project to my solution to create a console application that will be called every night buy the Windows Task Scheduler to perform routine maintenance tasks. This console application will be using the same database, repository layer, service layer, etc. as the web application, and both applications should share the same settings for the most part. I would like to avoid duplicating the settings in two files (app.config and web.config).
Also, I want these settings to be available to the service layer, which is in a separate project in the same solution.
I have read the following post, but I don't fully understand the solution, and I am not sure it is the best way to do this.
Sharing Config settings between Web App and Console App
I also read the article linked to by that post, and I don't find the solution very elegant.
I am using VS 2010 and EF 4.3.1.
If you're simply interested in accessing the AppSettings of your web.config file from a console app, that's simple enough. The only real annoyance is that since your console app won't be running in a web context, you will have to know in advance what your site is called in IIS. This being your own application shouldn't be a challenge.
Just use System.Web.Configuration.WebConfigurationManager to open and access the web.config of the specified site.
The idea is that you could put the settings into a common .config shared between all your projects as a link instead of putting it in all projects. The solution is outlined in this answer. Also checkout the configSource property on MSDN if you are not aware about the possibility of externalizing configuration elements into a separate file.
Related
Attempting to migrate a web part solution from farm solution to sandbox solution. The steps I have seen online outline changing a property at the project level which is a boolean called 'Sandbox Solution'. However I do not see this option when I view the properties of the project. Does anyone have and ideas on how to migrate a solution which contains multiple web parts from a farm solution to sandbox?
I am afraid this can't be done. When a farm solution is created and deployed it loads extra controls into the solution that allows the solution to easily access data outside of its container. An example is the user control. This control is not allowed in a Sandbox solution as it allows access to the SharePoint root. Just changing that option isn't going to revert that option because the entire solution is geared around it even if you don't use it. It will be deployed. I found the blog post you are talking about or one similar to it and have never seen that work. This is why you define your project type at the beginning because Visual Studio applies the different controls depending on your selection. Removing the sandbox and recompiling will not work.
On another note, you can however convert a sandbox solution to a farm solution. This is because you are moving from stronger security to "less"
This page shows how to enable profiling from the Publish Windows Azure Application dialog.
How can I configure profiling without using that dialog?
I looked through my service configuration and service definition files, and I can't find any settings related to profiling. The checkbox and radio buttons in the Publish dialog has to be configuring some setting file somewhere; I just can't find it.
I found it. Profiling is indeed configured in a settings file somewhere.
In case anyone has this same question, here's the answer:
Inside the Azure project directory, there's a folder called "Profiles". Inside that folder are some .azurePubxml files that (it looks like) correspond one-to-one with your service configurations.
Inside those files is a setting <AzureEnableProfiling>True</AzureEnableProfiling> that can be set to True or False.
So that's how you can turn Profiling on and off, without needing to use the gui tool for publishing to Azure.
Here's the scenario: I have multiple developers on an asp.net mvc 4 project. Each developer has a local database. The source control system is TFS at http://tfs.visualstudio.com. We're using Azure websites to host the site. We have also configured Azure websites for continuous deployment.
The source control system could be git, mercurial, TFS, etc. Honestly, I don't think it matters.
My question is how to accomplish these three things:
Each developer has his/her own connection string(s) locally (without them being in source control)
Azure has its own connection string(s) (without it being in source control)
Source Control doesn't show any connection information
The ability for each developer to F5 and run/debug/test the app locally.
We accomplished #1 by adding our individual connection strings to our machine.config so that there's no conflict between developer workstation setups.
I originally removed the connectionstrings section from web.config. In the Azure website (using the management portal, under Configure), I configured the connection strings, and after watching a Scott Hanselman video was under the impression that these would be dynamagically merged into my web.config upon deployment, but that doesn't appear to happen. Whenever I go to any page that hits the db, I get an error saying can't find the connection string (or some other db error related to the connection)
If I put the Azure connection string directly in web.config, Things work on Azure, but then the connection details are in source control visible to everybody.
After reading some more posts from Scott and David Ebbo it seems that I could put a blank connection string in web.config (with the correct name) and then Azure will overwrite the values correctly. I would then have to have the developers put their connection strings in their web.debug.config and then install the Slow Cheetah plugin so that they could F5 and test locally. They would also have to not check in the web.debug.config into source control. (Not that easy with TFS) This seems like a seriously burdensome kludge, that's bound to fail somewhere along the line.
I have to believe that this isn't that rare of a problem. How do other teams accomplish this?
After looking around, it appears that what I was asking isn't actually supported without a bunch of command line hacks to the pre/post build process. What we ended up doing is forcing developers to all create their own local databases, use trusted authentication, and establish a SQL alias that was used by all developers in the web.config. That way, it works locally for everybody, it doesn't expose any user names/passwords within source control, and Azure can still overwrite it when automatically pulled from source control.
Slow Cheetah is actually a nice solution. It's an extension to web.config transformations. Those transformations let you keep one web.config file and then for each deployment scenario you specify which changes you want to it. For example, your Release configuration will probably remove the debug attribute.
This can also be used to change connection strings. The transformations are applied during the deployment of your project to Azure.
What I've done in the past to make this also work with local development machines is use a web.config with an externalized connections.config file. Each developer created a connection.machinename.config file that was copied to connection.config on build in the post-build step. Those files don't have to be checked in and they can never cause conflicts because each machine name is unique.
The release/staging/.. configurations used a web.config transformation to replace the connection string element with a specific connection string for that deployment (and that way remove the dependency on the external config file).
Slow Cheetah offers some nice helpers for checking the result of these transformations at design time.
Scenario:
In my organisation, we separately develop multiple applications. In the end however, many of the applications (and their databases) are deployed to the same SQL instance, so they share the same master database.
We use Visual Studio 2010 database and server projects to source control said databases.
To try and standardise some things, I want to do the following:
Create a 'Core' Server database project which has all the server settings, core logins etc. Things like SET TRUSTWORTHY ON and server-level ANSI settings etc.
Have each Application's own Server.dbproj specify the logins and roles etc specific to that application.
Have each Application's own ApplicationDatabase.dbproj reference the ApplicationX.Server.dbproj
In theory, each Application in source control would only contain the items specific to it, rather than keeping server related settings or configuration synchronised across many projects.
Problem
However, in practice I can get this far:
Done. Produces a .schema file which I reference in future steps
Done. Server.dbproj happily references Core.dbschema and 'extends' it with it's own logins and roles etc. Is happy to deploy this anywhere I point it.
Nadda. I add a reference from ApplicationDatabase.dbproj to Server.dbproj (assuming Server would pull in the items from Core) and it complains about any logins that are actually in Core.
So I then added both Server and Core as references to ApplicationDatabase as it settled down. Compiles fine.
However, when you deploy, you get the same problem described here: http://social.msdn.microsoft.com/Forums/uk/vstsdb/thread/23cb9132-00d4-42ed-b34c-ab49027cddf7
Error TSD01234: The source model contains 2 server option elements.
Only one element can be contained in a model that can be deployed
The problem I think is that ApplicationDatabase essentially has two Server projects that it knows about, and therefore duplicate settings.
Microsofts documentation makes no mention of using partial projects in Server projects, but neither is it listed as a limitation.
So the question is...
Has anybody used partial projects successfully for Server projects, or is there a way you can see to achieve the same thing?
I'll be honest and say I won't just 'remove the Server projects' to make the problem disappear - we had it working very well up until I tried to improve things!
I have a C# Visual Studio console application with a service reference. The company providing the service offers two API's one for test and one for live. They are supposed to be essentially the same service but with different URL's to different servers.
When I right click the service reference and choose Configure Service Reference, I am able to enter the the URL for the live service; and my project compiles properly.
I am new to this and am not really sure if I should be reconfiguring the service or if I should be deleting it and re-adding it in? I don't know if there are .config files I should be changing or cleaning manually.
So I guess my question is - are there pitfalls or better practices for this process that I should be aware of?
Any advice greatly appreciated. Thank you.
I have worked with Service References myself and so far never had any problem with just updating the service reference. If you like/need to change the configuration, it is possible by editing the .config file that gets generated