When using VS, the preferred way to store user- and application settings seems to be to access VS "settings" tab for the given assembly and simply type the settings you need.
Monodevelop does not have this feature (or at least I did not find it...)
What is the preferred way to do this under mono using monodevelop?
If the answer is "well, do the same - but hand-type the code needed" I'd love some pointers to a nice tutorial.
On the mono list, John Ludlow had the answer I needed:
...First, the ConfigurationManager (
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx ) will expose two section handlers by default...
If you want more complex configuration option then you can define your own
handlers by inheriting from ConfigurationSection and ConfigurationElement.
See http://msdn.microsoft.com/en-us/library/system.configuration.configurationsection.aspx
and http://msdn.microsoft.com/en-us/library/system.configuration.configurationelement.aspx.
You may also need to provide a class inheriting from ConfigurationElementCollection
as well, if you want to be able to configure a collection of values.
Thanks to John and the people of the mono-list.
You still can use .settings files to keep settings, just edit them by-hand.
Also you can use App.config / another .config files
Related
So far I have two short questions:
1) What precisely are the benefits of creating custom nature?
2) Is it possible to somehow programmatically read files in [project]/.setting or [workspace]/.metadata/.plugins?
I'm using Eclipse Helios (3.6).
Ad 1. I've read that you can't have two natures ofthe same set, that you can use it to associate certain perspectives/tools (ex. builder) with it but well.. anyting else I can't do easily without nature? Ex. I can easily add a builder by modifying an IProject variable.
Ad 2. I tried to find a way to read project specific settings or plugin settings but failed. No specs, different file types, inconsistent XML tags... Is it at all possible without parsing them manually?
Thanks for your help!
Paweł
Think of a nature as a flag. All project-related functionality in Eclipse is triggered by natures. Project properties pages, context menu items, etc. appear based on presence of natures. Third parties can check for presence of nature to tell if the project is of certain "type". A nature also has install/uninstall methods. This gives you a convenient place to implement all actions that need to happen on the project when your technology is enabled. Why is that convenient? Because a third party can simply add the nature without knowing what else is necessary to configure and your code takes care of the rest.
Plugins write to [project]/.setting or [workspace]/.metadata/.plugins locations in different ways. The file formats are never documented as they aren't meant to be manipulated directly. Some plugins re-use the common ProjectScope and InstanceScope classes to read/write the data. Some read/write on their own. I would start with what information you are trying to read, figure out which plugin it belongs to and then see if there is public API in that plugin for accessing that information. Reading these settings directly is almost never going to be the correct approach.
I want to find all the child plug-ins of a feature ? I know the name of the feature, but IWorkspaceRoot.getProject(String) does not really help me. I get an IProject that I don't know how to convert to a feature object (IFeature ?). Maybe I am on the wrong track and there is a better / easier way to do this. Any ideas ?
You could check that a selected IProject is a feature project by checking for the nature called org.eclipse.pde.FeatureNature.
Then you could try to use IProject.getAdapter(IFeature.class) call, the cast the result to IFeature. I did not try this with feature projects, but works well with Java projects.
The correct answer is the use of PDECore static class. This class provides a FeatureModelManager, that would provide the corresponding information:
FeatureModelManager manager = PDECore.getDefault().getFeatureModelManager();
How to obtain this information? I looked with the plug-in spy to find which project defines the 'Deployable Features' export wizard (use Alt+Shift+F3 when the wizard is selected), and then looked at the implementation of the wizard class, where the addPages() method contains the previously described code block.
Like a lot of things, I'm sure there's a good reason for this, so please help me understand...
Why, by default, do WCF services store settings in app.config?
This has been so frustrating trying to work with multiple Silverlight class libraries. These class libraries are supposed to be completely independent from each other, and this dependency on the app.config seems to cause the following headaches:
Single Responsibility Principle - I should be able to add a reference to a class library and go. If that class library uses a service reference, this idea is shot before I even start coding against it.
Muddy Configuration - To get other libraries to work, I have to copy and paste the service configurations into the "main" application configs. If an endpoint changes in any way, I can't just worry about a new version of that class DLL - I have to worry about anything that uses it, too.
Complex Alternatives - Programmatically creating the endpoint isn't pretty. Period.
There has to be a better way. Why doesn't WCF at least separate the service configurations into a ServiceName.config or something that gets copied to an output directory. What am I missing? How do you deal with this?
Because the alternatives aren't pretty either. The problem with "ServiceName.config" is that ServiceName also needs to be configurable.
The root problem is having Service references in libraries to start with. And a library component cannot dictate a binding for an App. So your SRP argument does not hold.
I concur with #Henk - library assemblies shouldn't have WCF references. If for some reason it does require one, i would use dependency injection, and pass the service reference in to the library function - this is vitally important for maximum testing benefit.
I also don't buy your argument of "Programmatically creating the endpoint isn't pretty". Creating and assigning an end point is just a couple of lines of code, and is a technique i use almost exclusively with my Silverlight components (e.g. if no address is specified within the ServiceReferences.ClientConfig file then i fall back to known service locations within the hosting application, in which case those endpoints are programmatically created).
Basically, if you don't mind the couple of lines of code required to programmatically create an end point, then you can store your address details anywhere, in any config file. You only need to store the addresses in the app.config if you are going for a purely declarative approach.
By default all I get in intellisense are the functions and its signature. I would prefer if I could also get documentation with the intellisense. I realise that I am supposed to place an xml file that contains this documentation along with my dll.
From where can I get this is file? Or is there some other way for me to achieve this?
For the immediate future, there's no way to get the XML documentation short of grabbing the Structuremap source and building it yourself.
As for why that's not included with the distribution, I'm not sure. My only guess is that back when xml-based configuration with SM was more prevalent, Jeremy was concerned about confusion between StructureMap.xml the intellisense file, and StructureMap.xml the configuration file.
That's pure speculation however. For the real scoop you'd have to post on the SM-mailing list. Regardless, for the time being, you have to roll your own from the source. I've done this as well for the same reason, and it wasn't too painful.
-Scott
Edit - Instructions for doing this follow.
Using your favorite SVN client (if you don't have one, I recommend TortoiseSVN) grab the latest from https://structuremap.svn.sourceforge.net/svnroot/structuremap/trunk/ . If you want the same bits that are in 2.5.3, I think you'll want revision 234. Otherwise, just grab the head and build from that. (If you aren't familiar with SVN, find a tutorial that explains what I'm talking about)
Open up the StructureMap solution in Visual Studio (under the Source subdirectory). Right click the StructureMap project, Go to Properties > Build and ensure the option for XML output documentation is checked.
Build and enjoy.
Apologies if this is a duplicate, but I've not managed to find this question being asked directly.
The general opinion here (that's me and him across from me) is that they shouldn't, the reason being that DLLs can be shared; therefore the idea of having application-specific information in a DLL is nonsense. If the information is not application-specific, then constants can be used.
A further question is, assuming that DLLs do not have their own config file, whether DLLs should use the configuration files of the executable that loaded the DLL, or instead be passed the relevant data as part of some kind of constructor. Our opinion here is the latter, as it makes it more testable, the downside being that it will sometimes be necessary to pass a significant amount of data to the dll.
Opinions?
There's no reason why you can't have the best of both worlds in terms of "simple to configure with config files" and "testable". Have a static method which can create instances from the configuration file, but also provide a constructor for more control and testability. The static method would just grab the settings and call the constructor.
I believe it's possible to create settings classes for DLLs just like any other project, and then you just need to put the actual text into the application's config file instead of one for the DLL. Basically ignore the app.config generated for the library project, except to use as a template for the application's central one.
Alternatively, use something like Spring.NET to manage this sort of thing :)
Usually, I guess you should pass relevant information to the functions you're calling or set relevant properties in objects you're creating that are defined within the DLL. I guess that's why .NET does not really support config files for DLLs (you can create them, but they'll not be used when running).
I have one scenario, where DLLs are reading a config file, but that is very special: The .NET DLL exports objects as COM objects for use by Microsoft Navision. It communicates with a factoring bank using an XML-RPC interface.
While the DLL is installed on every user's machine, the configuration for the interface is common to all users, so I have a configuration placed on a network drive that's mapped on every PC and the configuration (URL, credentials, etc.) is read from that common file.
Whether that's good practice is up to the reader, but in that scenario having a common config file just made sense...