I made COM visible .NET DLL in C# which refers an external DLL and the external DLL reads app.config from current AppDomain. However my DLL is called from Visual FoxPro 9 so it misses content of app.config from my project.
Does Foxpro have something like app.config in .NET? I just need pass configuration to the external library via AppDomain from FoxPro.
VFP doesn't have separate AppDomains like .Net. However, if you put your DLL in the same folder where your VFP executable is, then your AppDomain.CurrentDomain.BaseDirectory is the folder where VFP executable is (IOW it is the same as VFP's justpath(Application.ServerName)). ie:
string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "app.config");
Also App.config is just a plain xml file. You can read and process its contents as you wish from within VFP.
VPF creates .exe file. Just create .exe.config file with the same content as dll.config.
Related
I have a .NET windows service made in VB.NET in Visual Studio 2013. In this project I have some DLLs referenced and also in app.config I have others defined as dependentAssembly (I didn't make this project).
When I compile this project, dependent assemblies specified in app.config are not being copied to output directory (debug or release depending on the case).
My questions are:
What is the difference between specifying dependent assemblies in app.config and reference a DLL?
Why dependent assemblies specified in app.config are not being copied to the output directory (debug or release) when compiling?
Can I force visual studio to copy dependent assemblies specified in app.config to outut directory (debug/release) when compiling?
Here is the relevant information I found about dependentAssembly. App.config should not be used on dlls, but only with executables.
If a dll is loaded in an executable, the dll will use the configuration file of the running executable and will ignore the configuration defined for him.
If you like, you can read the configured keys using some ugly code that takes them from the configuration file for the current assembly.
What you should do is put the relevant configuration into the exe configuration file. You can checked in this link for more details.
I have a Class Library, which is called by a VB6 client and VB.NET client. If the Class Library is called by the VB.NET client then there are settings in the app.config for Log4Net (http://logging.apache.org/log4net/). If the library is called by the VB6 code then there is no logging at the moment.
The question I have is about the app.config. If I have an app.config in the VB.NET client (Windows Forms) and the class library, then I assume that:
If client is Windows Forms then
Use VB.NET App.config
ElseIf client is VB6 then
Use Class Library app.config
Is that correct. I have done some research on MSDN, however I cannot find anything explicit and hence the question.
I don't think class libraries support app.config files directly - they merely use the app.config / web.config of the assembly that forms the process - so the console app, service, WinForms App etc.
app.config files are useful only to CLR executable assemblies and they are automatically loaded when the application runs.
If your executable is not a managed application (application developed using VB6 I assume), app.config is useless because CLR won't get loaded into the process (since it is not a managed app).
If your assembly is managed but not executable (class library), it is useless (useless in terms of execution, otherwise it can be used to copy the contents to an executable project's app.config).
Class library uses the config file of its host, so even if the class library project has a config file, it will not be reference at run time. Instead it will look for the config file of the host executing the DLL.
To avoid recompiling the code after the build to update a variable values like Development DB and Production DB, etc. You can either use setting or hard code a path in your program to look for a 'config' file. I use an XML file, with a key-value pair. I then load and read it to a list, or dictionary that i can use in my application like a 'config' file.
Now when I deploy, I can simply change the 'config' file in the hardcoded location in my dll to whatever environment without the need to rebuild the class library.
I just inherited a VB.Net application that gets a SQL connection string like this:
Dim m_GMSConnString As String = System.Configuration.ConfigurationSettings.AppSettings("connString")
But there's no app.config file in the solution/project. So where is it reading from?
EDIT: If this is a DLL project and the DLL is then referenced by a website project, will the DLL read from the web.config of the website project? That's the only explanation I can come up with.
EDIT: If this is a DLL project and the DLL is then referenced by a
website project, will the DLL read from the web.config of the website
project? That's the only explanation I can come up with.
From my experience (and it is confirmed here Why wont my application read my MyApplication.dll.config file?) answer is yes, the code will only read the app.config of the main project (or web.config in your case).
But the answer also provides link that show how to use multiple config file. I think you can tell your program to read some part from external file (your dll.config file in your case).
if I remember correct, there is a config file with the same name as the exe file but add the extention of .config, such as yourprog.exe.config
I want to use reg-free com so that I don't have to register my legacy com component. However, I would like to be able to put the com dll in a location which is not in or below the directory of the client exe, e.g. ....\lib. I'm not able to do this in the server manifest file as it doesn't allow relative or absolute paths.
Does anyone know if there is a way round this?
UPDATE:
I only found relative paths to work on XP. However, I can use absolute paths on Windows Server 2008 using the Activation Context API so that's cool. My problem now is that my COM component has a static dependency on a managed database driver but currently it's not finding it. From what I've read about manifest files I hoped I could simply add another element to the COM reg-free manifest pointing at this dll as it is in the same directory as the COM dll but I can't get it to work. So, in summary, I have an exe in one directory which uses Activation Context API to reference a COM manifest/dll in another directory (that is not a subdirectory of the exe directory) which it finds and loads correctly. But I also have a managed database driver dll in the same directory as the COM dll and I want to know how I can get this to load using manifest files - if it's possible.
I've achieved this by running the exe with the parent directory as the current directory.
i.e with this folder structure
parentdir/
parentdir/myapp/
parentdir/somedependency/
Then with "parentdir" as the current directory, you can run your exe as
".\myapp\myapp.exe"
and myapp.exe.manifest can contain a reference to something in "somedependency" as
<file name=".\somedependency\somecomassembly.dll" />
This works on Windows Server
I have a website solution that contains three different Silverlight 4 projects, and they all make use of the same Silverlight class library.
I have done this by creating a class library project within the solution, and referencing it from the other Silverlight projects.
BUT the class library is included in every one of the XAPs. The user could end up downloading the same class library multiple times.
How do I canvert the class library into a XAP that can be downloaded once, in the same way that an assembly is?
(And why isn't there a Silverlight Assembly project type in Visual Studio?)
You should use Assembly Caching - it's a way to leave dependent assemblies out of your xap file. Instead you need to deploy them with your xap file by placing them in a seperate zip file in the same folder.
In the properties window of your Silverlight application you can choose to enable Assembly Library Caching. That will automaticly generate a zip file for each cacheably assembly.
In the project References folder in Visual Studio, select the referenced dll that you don't want to be loaded again, and in the Properties window set its Copy Local property to false.