This question already has answers here:
Can a class library have an App.config file?
(7 answers)
Closed 4 years ago.
I have a (very) old c# desktop app which I've inherited and I need to move hard-coded values into a settings class. This setting class belongs to a class library. However when I publish the main project (which is the windows application) none of the settings from the class library appear in the published app.config.
So : have a VS 2017 solution with two projects: a class library and a winforms app. Both have a Settings.settings class; but when I publish the winforms app the resulting app.config only has the settings from the winforms app project.
Do I have to move the settings from the class library to the main project to have the published in the app.config? (which would seem odd as the code for the front-end doesn't use these settings directly)
Or is there some way I can ensure the settings in the class library are included in the app.config when publishing?
The "App.Config" file is populated from the "resources" tab in your project properties.
If you make a "settings" class ('SettingsClass.cs'), this will indeed not visibly show up in the compiled product. such a class is useful to make it easier to find and change values during the design process, but it does not allow for easy updates (although it also makes it harder for end-users to inspect said settings).
if you want to be able to easily see and change values in the compiled product (trough an updater, for example); you will need to use the project properties, or use some other method (excel file, xml file, sql database), with a (custom) reader class
Related
I used to program WinForm .net Framework Applications. There I used the .exe.config (via "Settings" - Scope "Application" in VS).
With that, I could change the entries of the .config file after being deployed, and I was able to access these changed entries easyly via Properties.Settings.Default..
Is there an easy way to do similar things in .net6 WinForms? I couldn't find "the whole story" anywhere (how to define such settings, how to make them editable after having compiled the program and how to access the Settings in cSharp.
Apologies if this has been asked before; after two days of searching I can only find partial answers that don't fully relate to my situation, and are difficult to follow with my lack of experience.
I have a solution that contains four projects:
Class library (containing database connection strings, email server settings, plus lots of other settings)
Web application (web forms)
Web application (MVC)
Web API
Projects 2,3 & 4 all reference the class library, and use the database connection strings, etc, to function. These projects also contain their own additional settings in web.config, bespoke to that project.
Everything works great so far... However, I now need to publish client-specific versions of my solution, e.g. the solution for ClientABC requires different settings for each project than for ClientXYZ. All other aspects remain the same, it is simply the config settings across the four projects that need to change.
From my research, I hit upon something called SlowCheetah which transforms the config files based on the publish profile. That sounded promising, but then I get this problem, where the class library settings aren't pushed into the other projects. I can see bits of useful info in this question, but don't have the experience to apply it to my problem. I'd rather not duplicate the settings into respective project's config file if possible, as that feels messy.
Can anyone please offer me some help as to what's best here? I don't even know if I'm taking the right approach, but am pretty sure I can't be the first ask this?
but then I get this problem, where the class library settings aren't pushed into the other projects
you have to keep in mind that the configuration file is readed by the SturtUp application, your client. Class Library can't run directly, but inside a WebApp or WinApp or ConsoleApp
So, any settings that you put in your ClassLibrary configuration file must be copied in the configuration file of your WebApp.
Generally, I copy some settings from app.config to web.config but, if you search on internet, you can find a method to automate this operation.
I now need to publish client-specific versions of my solution
You can create many configuration profile and use a web.config transformation:
From ToolBar or Build Menu, select Configurazion Manager...
Create all configuration you need for clients
Now you can see different web.configuration files
Now you can specify different configurazion transformation for your ClientABC, ClientXYZ and publish them with specific configuration
EDIT:
So, you can adopt this solution for your Class Library too, or external config file, and include external file in your web.config: External Config
I have a windows application (winForms). I would like to refactor it such that all functionalities are built to .DLL file so that when winForm is run, it will just call .DLL. In addition, I would be creating another .exe which is Console App so when a user wants to just "schedule task" it, he will create a config file that will run the console app, which when run will also call .DLL
I don't have much knowledge about refactoring and compiling projects to .DLL (I hope I am making sense)
I just want to know if I am correct on how I quite understand it for now:
Should I transfer all my functionalities from winForms to a class that will be compiled to .DLL? Or if I am wrong, what should I put in a .DLL class?
You should create a new project in your solution. Create a class library project in your solution in Visual Studio (or tool of choice, you did not specify what you are using so I assume VS).
To add a new project, right click your solution and select Add submenu, then New project.
From the categories menu on the left, select Visual C#, then Windows, and Class Library.
Then you should add a reference to this new class library project from your current WinForms project.
Right click References in your current WinForms project and select Add reference.
Then select Solution category on the left (VS2012), or Projects tab (VS2010) and Select your newly created class library project from there.
Then you can start moving classes from your current WinForms project to this new class library project. Class library project will be compiled as a dll and you will have access to all classes in this dll from your WinForms project.
Nothing dramatic is needed. Just Project + Properties, Application tab, change the Output type setting from Windows Application to Class Library. Done. You may have to declare a class public if you didn't already do that. You could remove your Program.cs source file since it won't be used anymore but that is entirely optional. A good reason to not remove it is keeping your project testable.
Fwiw, changing the Output type setting is not actually necessary, .NET doesn't distinguish between a DLL and an EXE at all. The CLR loads assemblies by their display name, it doesn't include a filename extension. You can add a reference to your EXE assembly in another project and it will work just fine.
So doing nothing at all already works :)
I have an app MainApp that references another project MyDLL.dll. Inside the MyDLL project I have made some user settings in a Settings.settings file that may be changed at runtime. So it appears that these settings get saved in the app.config file of MyDLL. But the problem is, the main project is MainApp, and MyDLL.dll.config does not, so far as I can see, get copied to the MainApp output folder. This is reflected in the fact that even though I save the settings in the code of MyDLL, the next time I run MainApp the settings have gone back to the default.
I must be missing something really obvious here. There has to be a way for related assemblies to preserve their settings values. But how?
While you can add an app.config to a library project, it has no effect to do so. Configuration is linked to the application, not the library.
You need to create the settings and configuration in your application itself. You can do something like including the library's app.config if you really wanted to, but that would probably not do what you want, either. It's best to just handle your configuration in the application.
Why is this so? Because what's to say it's valid to have user settings for your library in the first place? A library should not be tied to any particular kind of application. What if you used it in a Windows Service or an ASP.NET application?
How can I have code-sharing between two projects without making a dll?
The issue is: I have a tool that syncs users & groups from LDAP to a database.
Now the tool is a windows service, but testing it as such is very difficult and time consuming.
Which is why I made a console application where I can test the LDAP syncing, and then just copy the respective sourcecode-files over to the service project.
But... keeping the common files in sync is a bit of a problem.
I don't want to make a dll, because this probably creates me a problem with
the 3rd project, a windows installer (for the service) where I have to use ExecutingAssembly path...
Is there a way to share the code without making a separate dll?
Automagic statical linking, so to say ?
How about adding a file as a link.
In Visual Studio right click on your console test app project -> select add existing file -> in the file add dialog navigate to files in your actual windows service project -> select the files you want to share -> and on add button select add as link option.
You can add a file to a project as a link. On the Add Existing Item dialogue the Add button has a drop down on its right. Use this to select "Add as Link":
Put the file as a solution item and add as a link to each project.
How about hand-modify the project files to point to the same source file?
Another option - put both projects in the same folder. Add a class to one, then in the other project add existing class and point to the class just created.
You could:
maintain the shared code in a separate project that produces a DLL and then use a tool such as ILMerge to turn the DLL & EXE into one assembly.
share the source-files between multiple projects, either by tweakiing your project files or doing something funky with your source-tree layout.
All that said, the best approach would be to bite the bullet and store the shared code in a shared assembly (DLL). What happens when you decide to, for example, expose this code via a WCF service? It starts getting more complicated then as you have 3 places that reference the same code files. Don't just think about what makes your life easiest now, think about what'll make your life (and that of anyone else who has to maintain the code) easier in the future as well! =)
Necromancing - As per Visual Studio 2017:
You can create a shared project, and then reference the shared project in another project.
It will use the framework-version and libraries from the project you reference the shared-project from. You can also use the same shared project in multiple projects, provided you get no conflict.
This is basically statical linking on a source-code level.
This also works with HTML&JavaScript-files (specifically, it works with publishing), but with HTML & JS files, you will run into problems while debugging...
It's under "Classical Windows Desktop", but you can also use it for .NET Core etc.
If you want to share functionality, you should use a DLL or similar.
Since what you want to share is the source, what you are essentially sharing is file sharing. So you can do that by making your projects reference external sources or you can have your source control do this for you.
If you are using Visual SourceSafe, you can make a link between two folders. VSS will make sure that they are treated as the same file.
I'm going to describe the setup we use to manage and test our Windows Service projects. While this doesn't answer the question of "sharing code without a DLL" (Unmesh's answer takes care of that), I think the OP probably doesn't realize how easy this is with a DLL. In any case, I'm hoping it will help someone.
Create a solution, LDAPSync. Create three projects in this solution:
LDAPSyncLib
LDAPSyncSvc
LDAPSyncTest
LDAPSyncLib is a DLL project that contains all of your business logic and main functionality.
LDAPSyncSvc is a Windows Service project that contains two classes, a service controller class that inherits from ServiceBase, and an Installer class for your service. This project has a "project reference" to LDAPSyncLib.
LDAPSyncTest is either a GUI application (WinForms, WCF, etc.) or a console application, depending on your needs. This project also has a "project reference" to LDAPSyncLib. Its sole purpose is to provide some interface which allows you to easily make the required calls into your business logic for testing purposes. In Visual Studio, set this as your "StartUp Project".
Now, when you run in debug via Visual Studio you will get a nice little GUI or command window that you can use to manually make test calls. When you install it as a Windows Service, the LDAPSyncSvc project's controller class will take over and handle all of the necessary service requests (start, stop, pause, etc.)
We have around 30 in-house Windows Service projects that we've been continuously managing, developing and testing for over a decade and this workflow has proved invaluable in quickly finding and fixing bugs when they arise. Best of luck with your project and I hope this helps some future Googlers.