Scenario:
I have 2 Projects, MainApplication (which compiles to an exe) and ClassLibrary1.
Now MainApplication references or loads ClassLibrary1, but ClassLibrary1 has no idea about MainApplication.
But I want to use Settings (Dot.Net 2.0's Properties.Settings NOT appSettings) that are defined in MainApplication.
How do you achieve this?
I have seem PLENTY examples that use
System.Configuration.ConfigurationSettings.AppSettings.Get("SettingName");
This is NOT relevant to my situation as appSettings is old school and I am using the newer Properties.Settings mechanisms.
Your help is appreciated :)
I have done some investigating in code.
I can get the setting like this but it is really dirty:
((ClientSettingsSection)ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).SectionGroups["applicationSettings"].Sections["MainApplication.Properties.Settings"]).Settings.Get("Tester").Value.ValueXml.InnerText;
Maybe someone can provide a more elegant solition
Since the Settings class is defined on the Main project, you cannot directly access it from the class project because you would create a circular dependency.
What you would do is provide the Class library with a delegate it can call to dynamically retrieve the settings from the main project. Create a class that stores a delegate in the Class library and set this delegate to a method defined in the Main project. This methods would encapsulate the instructions needed to retrieve a setting.
And in my opinion, appSettings is not old school, it is just a way of representing configuration parameters that are not specific or customizable by a user.
Related
How can I access a class which is in another project in C#. Please keep in mind that I cannot add any reference due to creating circular referencing.
Is there any way?
Not without some refactoring. Reflection could help but you still wouldn't be able to extend from that class or use it in any non runtime way.
I have found that this can happen with minimum refactoring
Identify the shared code
Extract it to a new shared project
Add the new project as a reference to all projects that need it
I am working on a WPF project using MVVM pattern. In solution, I have viewmodels,models,views and properties.As per requirment, I need to access the same classes(view models, models, properties) from another class library in same project. I do not want to add the reference to the class library as it is an exe file and a heavy component which has got so many classes which i do not require. So, is there any solution for this. How can i access same classes(view model,model,propeties) in a solution from another class library in same project?
Thanks & Regards
You have two choices. First one, is to refactor your exe in order to extract the reusable classes to a separate dll. Then, just add a reference to this new dll.
The other is to use reflection to access the members of the exe, which is the worst option, even worse than simply adding a reference to the big old exe.
I suggest breaking down your solution further in more projects, For example separate projects for Model, View and ViewModel or perhaps breaking down even further and then add reference only to the library you need. That way you are not exposing everything.
The other option is reflection which may be cumbersome to use and make your code ugly.
I have a class named CreateListView in my project in a .cs file and I am able to use it by including it's namespace in my usings at the top of my page. Is there a way I can compile the file so that I can still use the class but users are not able to see the contents of the class. I want the users to still be able to create objects from that class but I don't want them to modify it and it will also be better if they could not see it.
You can put it in a separate project (Class Library), compile it as a DLL and give others the binary to use in their projects.
As others have said, you want to compile it into a Class Library, and then distribute the resulting DLL. If you really don't want them to be able to see into it with a tool like Reflector, then you should also consider using an obfuscator.
You would want to place the code in a seperate project and then build it and give them the .dll this will allow them to use the class you've created but not see the code.
I wrote some classes that I use with many different projects.
For example, I use Library.Controls.FlatButton.cs almost in every project.
The problem is when I add this as an "existing item"; the class gets created/copied in my soultion folder everytime. And each time I edit/update the contents of that class, I have to update all the Library.Controls.FlatButton.cs files in every project folder.
I need to be able to edit a single source of FlatButton class and when I compile/build a project (that uses the class file) gets updated to the new version of that class.
Question 1: Is there a way to do this?
I know that I can gather all these classes in a library project (Library.Controls) and add it to each application solution as a dependency.
Question 2: Is this the only way to work from a single source of common library files? And if I do; will all the classes in the Library.Controls namespace get compiled with every application, even if I've only used this FlatButton class in the project?
Hope this is clear for you..
thanks
I'd rather go with the approach of the shared library and add them as references to your client project.
If you don't want to do this. You could add the file as "Link". In Add existing item, select Add as Link instead.
Yes, a class library is the way to go and yes, since the whole class library will be referenced from your applications, all the classes will be available to it.
However, the fact that all the classes are available is not a bad thing, since they're in a separate class library it won't make your applications harder to understand (since the amount of code in those applications will stay the same), it might just be that you use up a little bit more hard drive space, though if you really worry about that you could put the class library in the GAC so that all apps reference the same copy of the library, though you'd better research this first to make sure that it's suitable for you.
Alternative way is to add FlatButton.cs file "As Link":
I have a set of methods that do some utility work over SQL connection, and until now these have been copied over from project to project. But as time goes on, project numbers have grown and I need to keep these methods in sync in case I find a bug or need to update it.
I have managed to get it to the state that SQL access class is a partial class, one part is specific for project and contains wrappers for a specific database. The second part is the common one and contains methods that are used in all project-specific databases.
The problem is that now I would have the "utility" class copied over 8 projects, with the same content, but in different namespaces. In C/C++ it would have been simple, because I would just have #included the contents of the file wherever needed. What should I do in C#?
Separate out the class so that you can have a complete class containing all of the common code, in a common project. Use a common interface to represent the bits of functionality which will be project-specific, implementing that interface in each project and passing an instance of the interface into the common code where necessary.
As Jon says, a library assembly is a good idea.
There are some situations when an assembly reference doesn't lend it self to the requirements so, if creating a library assembly is not an option, it is possible to use a feature easily overlooked in Visual Studio, adding an existing file as a link.
This would allow you to maintain the common part of the partial class in a file that is available in all your projects.
The only restriction is that a relative path is used to reference the file.
The only problem I have had with this strategy is with the open source Mercurial scc provider. When removing a linked file from a project, the underlying file is deleted. Quite annoying but this may not be an issue for you.
Update: The linked file bug in the VS Mercurial SCC should be fixed in the next release.