I have a problem using a dll with a service reference that should read a custom configfile.
My situation is as follows:
- DLL which read its own config file (by using configurationManager.openExeConfiguration(dllname.dll.config))
- main application which uses the DLL (3d-party application)
This is working fine, the dll reads the right configsettings.
Now I must add a service-reference to my DLL. The problem is that it tries to read the standard app.config file (which doesn't exist), instead of reading the dllname.dll.config file.
Anyone has a solution for this?
Thanks,
In .NET, it has never been the intention that libraries should have their own .config files, so there's no official support of this and lots of issues are sure to abound.
Although you can read such a file with ConfigurationManager.OpenExeConfiguration, this was never the intention of that API - it's mainly there to provide an API for editing application .config files.
You would be much better off if you let the library read from the app.config file instead, using the standard ConfigurationManager API. You can still have custom sections for your library in the app.config file. This is the way it was always intended to work, and it will give you far less trouble.
Not to revive an old question, but since it's unanswered I'll chime in.
While playing in the config section as of late, I cam across a couple of great resources. One goes in the the details of having clients and servers read custom configs by basically inheriting from the ServiceHost/etc. and overriding the methods that load the configuration.
Now, granted, I do agree with Mark, there are always exceptions and cases where this method could provide additional flexibility. I just felt compelled to pass along the article in hopes you'll also appreciate it.
Related
I have a large bespoke container file (~3TB) in size, and another application that needs to read from it.
However, the application doesn't understand the structure of the container, so I have to convert it first, which means creating another ~3TB file; I'm hoping to streamline this process.
What I'd like to do is to create a file/pipe/something on the file system, and when the other applications reads from it, my application simply returns the correct data from within the container.
I'm not sure if this can be done in C# and I don't really want to have to hook any OS components, so I was thinking that a named pipe might work, but I'm not sure, if anyone has any suggestions or ideas, I'd appreciate it.
If you don't control the consuming application and it expects to be reading from the file system, there may be a way of doing this but it's a fair bit of work.
Recent releases of Windows 10 have included the Windows Projected File System. Windows takes care of all of the file system interception and you just have to be able to answer questions like "what files are meant to be in this directory?" and the like. I believe it's now used for OneDrive and that's one of the intended uses - where the actual files may normally reside in cloud storage rather than locally.
You do have to make file content available as Windows demands it. The one thing to say though is that it's not an easy job direct from C#. If you're going to try binding to this API, it really helps if you understand a bit of C or C++ too.
Earlier this year I was looking to create a managed binding to this API to make consumption easier from .NET languages. It's not, however, currently in a releasable state. But the basics worked and proves that this is a viable approach.
Once .NET Core 3 is fully released I'll probably dust this off again and make it work well, but for now it's a WIP
All, I have a large C# application that I am writing a plugin for. I want to provide settings for this plugin and came to the conclusion that writing my own setting manager ect. and creating XML settings which would be put in the relevant special folders is the best way to go. However, I can't remember why (after coming back to project) I came to that conclusion over using the Properties.Settings.MySetting route. Can someone offer any advice in terms of what method is more preferable in my case?
Is writing my own overkill here, or is there a clear and obvious benefit?
I aplogise if I have asked this on the wrong Stack site.
Thanks very much for your time.
It's a good question and I'd like to let you know that you came to that decision because your DLL plugin cannot normally work with its own app.config file (where the settings are stored).
This happens because the ConfigurationManager looks for app.config files attached to the executing process, which is main exe file.
You got several options over here, and the best one is to point the configuration manager which file to use as a config file which is greatly described at this page.
Im reading 2 books about WCf and one of them is showing Configuration as App.Config and the other is showing via Code in C#
I want to know which approach should i use and what are the benefits for each other.
Does the Wcf Configuration Wizard supports also the c# code behind configuration ?
thanks for the answers.
Configuration files can be changed without a rebuild (handy, say, to add a custom inspector or serializer), is pretty easy to copy/paste between client/server, has support from the IDE tooling.
Code is handy if you are configuring the system at runtime (i.e. getting the information from another server), or are running as a library (dll) and can't guarantee that a configuration file will a: exist, or b: have your configuration. Code also has intellisense / static checking to avoid brain-dead errors (typos in the xml etc).
I'd use a file until you know you have a scenario that doesn't work well with a file.
Also consider: how hard is it for you to deploy a code change vs a configuration change? for me they're about the same, but that might not be the case for you. Maybe it is easier to just change the config on the machines? maybe not.
I guess it depends on your needs. I personally tend to configure wcf with code, especially for things that are unlikely to ever change. That might include error handlers/logger, behaviors, authentication modules, service host factories, etc
For more dynamic stuff, like connection strings, passwords, file paths, etc are configured in .config files.
One of the biggest advantages of using code is that your code now can support things like IOC/Dependency injection, compile time checking, etc.
I don't buy into the idea that everything should be in a config file because it's easier to change it. In most cases I've seen it never changes in production.
The configuration file approach is better, it gives more flexibility. For example i change the authentication type (username password/windows) by changing config files.
Our internal HR application is developed by the vendor, but I've been given a requirement to change the behaviour of a certain piece of functionality without their assistance (which I don't want to do, but am investigating...). The functionality in question is an .ashx page which does a number of database lookups, and is called via javascript functions on a web page. We want to add one further database lookup.
We have control over the javascript code, so that's not a problem, but the code for the .ashx page is held in a compiled assembly. I've found where it is, and looked into it using .Net Reflector. Reimplementing the methods involved wouldn't be difficult, if it were technically feasible.
Can I create a new assembly, paste the source taken using Reflector into it, make my modifications, add the DLL to the application, and then set up a new .ashx to refer to it?
The bits I'm worried about not being possible are:
The code refers to some vendor classes held in other assemblies; can I just add references to those assemblies in Visual Studio to allow it to compile, and then when it's compiled and put on the server it'll all work?
Will I have trouble getting the web application to accept the new DLL, given that generally this application is not something we make changes to ourselves?
EDIT:
Some clarification: I'm not actually planning to replace the vendor's DLL with one of my own, that does sound like going a bit too far. Instead, I would make a new DLL with just the one function in it I need (based on stuff taken from the existing DLL using Reflector). I'd need that code to reference other utility vendor code so that it can get at classes needed to access the framework. I'd make a brand new .ashx page to serve up the code in the new DLL.
Luckily after all this I'm off the hook, because my customer agrees that things aren't desperate enough for us to attempt all this! But thanks for the assistance, which is definitely useful.
See my comment about the risk of the approach you're considering.
I really don't recommend the overall approach, but yes, it is possible to reference assemblies you don't have the source for; just add references to the project which will use them.
Replacing the code-behind for the .ashx may be possible depending on whether it's precompiled. If it's not, then I believe replacing the DLL in the BIN folder should do the trick. (Assuming no other assemblies are referencing it.) (DISCLAIMER: I've never tried this, and I don't recommend it.)
If you are just looking to get some additional data, I'd just implement my own lookup and call it from Javascript, rather than messing with reflector. Is there any reason that you can't do that?
I'm reviewing a .NET project, and I came across some pretty heavy usage of .ini files for configuration. I would much prefer to use app.config files instead, but before I jump in and make an issue out of this with the devs, I wonder if there are any valid reasons to favor .ini files over app.config?
Well, on average, .INI files are probably more compact and in a way more readable to humans. XML is a bit of a pain to read, and its quite verbose.
However, app.config of course is the standard .NET configuration mechanism that is supported in .NET and has lots of hooks and ways to do things. If you go with .INI files, you're basically "rolling your own all the way". Classic case of "reinventing the wheel".
Then again: is there any chance this is a project that started its life before .NET ? Or a port of an existing pre-.NET Windows app where .INI files were the way to go?
There's nothing inherently wrong with .INI files I think - they're just not really suported in .NET anymore, and you're on your own for extending them, handling them etc. And it certainly is a "stumper" if you ever need to bring outside help on board - hardly any .NET developer will have been exposed to .INI files while the .NET config system is fairly widely known and understood.
Ini files are quite okay in my book. The problem is GetPrivateProfileString() and cousins. Appcompat has turned that into one ugly mutt of an API function. Retrieving a single ini value takes about 50 milliseconds, that's a mountain of time on a modern PC.
But the biggest problem is that you can't control the encoding of the INI file. Windows will always use the system code page to interpret strings. Which is only okay as long as your program doesn't travel far from your desk. If it does, it has a serious risk of producing gibberish when you don't restrict the character set used in your INI file to ASCII.
XML doesn't have this problem, it is well supported by the .NET framework. Whether by using settings or managing your config yourself.
Personally I never user .ini /xml config files to anything more than loading all the values into a singleton or something and then use them runtime like this...
That being said i firmly believe that you should look at the kind of data and the use of data. If the data is in the context of the application in terms of settings and comfigurations then i believe that the app.config file is the right place to hold these settings.
If on the other hand the data is concerned about loading projects, images or other resources concerned with the content of the application then i believe the .ini (does anyone use .ini files anymore? I am thinking a .xml file for storing these information). In short: Segment the content of the data being stored according to the domain and the context.
INI files are preferable for multi-platform applications (e.g., Linux & Windows), where the customer may occasionally edit the configuration parameters directly, and where you want a more user-friendly/-recognizable file name without the extra effort.