I have a Visual Studio web application solution. I have three projects as UserInterface, BusinessLogic and DataAccess.
I had to store some user defined settings and I created configSections in the config file.
I access these configSections through classes which inherit from .NET's ConfigurationSection base class.
So in short for every project I had a separate configSection and for that corresponding configSection I had a class in that project inheriting from ConfigurationSection to access the config section settings.
This works all sweet. But the problem arises if there is any setting which I need to use across multiple projects. So If I need to use a setting defined in UserInterface project configSection in, let say, BusinessLogic project I have to actually make a copy of that setting in the BusinessLogic's configSection. This ends up having the same setting copied across multiple configSections.
Isn't this a bit too redundant?
Never actually done this, but in theory it might work...
When you define your custom configuration section, set its configSource to an external file (whatever.config). This external file should be added to the SOLUTION and not the project. It will appear under "Solution Items". In each project, Add an Existing File, browse to whatever.config, click the dropdown on the Add button and select "Add as Link."
Whatever.config will be a single file you can edit under Solution Items, and it gets copied into each application at compile time.
Using your example:
Just create the setting in the Business Logic project and then expose a Getter to the User Interface project.
Then the UI can query the BL for the value. Your configuration setting is only in one place - the lowest level it can be.
However, if you replace a lower level project with a new one you'll have to make sure that the setting is replicated too. This is only likely to be an issue if the setting is in the Data Access level as that's the one most likely to get changed (different database provider for example).
There is a much better way of doing this using "Shared Projects" see my Answer on a very similar question here.
Related
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I have a C# solution I created within Visual Studio 2010 Ultimate that contains multiple projects that make use of the same structures, classes, and enumerated types. I have created a .cs file that contains all of these items, but at the moment I have to make a duplicate of this file for each project. This is obviously less than ideal because I have to remember to update each copy of the file should I make a change or addition.
Is there are way I can have all of the projects reference just one actual copy of this file, so that I only have to update it once and all of the other projects can see this update? A colleague of mine told me it was possible to make some sort of "symbolic" reference in TFS, but since I don't really know what the name of this feature is I don't know how to research it further.
This question has answers that suggest either creating a class library or using "Add as link" when adding an existing item. I suppose I can do this in Visual Studio when not using TFS, but I have posed this as a TFS-specific question. Will this "add as link" option work when TFS is in use or do I have to do something in TFS to get it to honor the link reference?
"Add link" option would definitely work with TFS. You dont have to do anything specific for that. "Add Link" is project specific and it will add a new entry to your project file specifying the location of your .CS file. As long as the file is available in the particular location during server build, there is nothing to worry. Make sure that the Add link makes a relative path to the file and not absolute.
In my company, we have multiple projects within a solution and we share a single "Assemblyversion.cs" for all the projects so that I dont need to write version info in multiple files. We have made use of Add Link and it works great!
Is there any way one can define for a solution a global variable accessable by any project file or project property sheet included in the solution?
One variable is enough if that can define a path for a property sheet that every project can include.
This is desirably for a solution.
An environment variable would be ok though less desirable.
** (visual studion 2010)
Poking at it again, I can't see how to set a user defined $(xxx) vartiable in a project - yes you can in a property sheet, but In a project I have reference to the $(ProjectDir) -
The problem is I want to define a $(tree of projects root) that any project that references a specific poject can access and the root will be relative to that project.
An alternative would be if a property sheet can have access to its own path and define the project collection root (of a tree of related projects with common resources) relative to that.
It seems every one building a big system with VS has the same problem.
I don't know your use case but it doesn't sound like the best idea. This will tie all of your projects together very tightly, which violates good OO design. Microsoft hasn't included any solution-level properties for this reason. However, if you really want to do something like this, you have two ways (at least) to go about it.
The first way, and the way I would recommend against, would be to store the variable in one of your projects and make it public. Then all of your projects could access it as long as they include the project as a reference.
The second way, and the way that will retain some OO principles, would be to create a config file that all projects looked at for the variable. This could be an XML file, a CSV file, or even a simple text file. If you wanted to get more complicated, you could point to a database location since this is one of the roles of a database.
I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.
Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.
I'd appreciate any alternative approaches too.
Edit:
I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.
The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following
Right Click on the project and select "Properties"
Go to the Settings Tab
Click on the link to create a default settings file
This will create a couple of files in your solution.
Settings.settings
Settings.Designer.cs
Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property
Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx
Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.