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
Related
I am trying to make Rest Call through C#, to do that I am using RestSharp dll.
I have created farm level solution and added webpart, then installed RestSharp through NuGet.
The issue I am facing is in following line:
var client2 = new RestClient(webURL);
The moment I add this line, I am getting 'does not have strong name' error.
Referenced assembly 'RestSharp, Version=105.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
Then I created a console application added same dll and tried, it worked.
Then I created a simple web application and then added same dll and tried, it worked.
It is only failing when I am trying through webpart.
I really appreciate if anyone can guide me or give me some tip to solve this issue.
Have you tried signing your DLL with the key.snk file provided to you in your SharePoint project? Most of the time, 3rd party libraries need to be rebuilt with the snk file.
You just need to use ildasm to convert your dll to an .il file then use the ilasm to sign your il file with the snk file and convert it back to .dll
Let me know if you need more details regarding this.
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 was converting some .NET-3.5-based projects to .NET Framework 4.0 and ran into trouble with assembly-embedded string resources.
The code contains references to resource strings like Resources.ValidationFailedMsg. Resources here is an automatically generated class. It's fully-qualified name is MyAssembly.Properties.Resources (the assembly name is MyAssembly.dll and, to keep it simple, the root namespace of everything in it is also MyAssembly). The project's "Properties" folder contains Resources.resx, where the string ValidationFailedMsg is defined (e.g. "Validation failed!") and the Resources.Designer.cs file is generated from it.
Now let's run this thing. Here's what happens:
System.IO.FileNotFoundException : Could not load file or assembly 'MyAssembly.resources....
Excuse me, what file???
First, I understand the concept of binary .resource files and how there may many such files for many cultures, but let's get one, default culture to work first. From .NET 2.0 to 3.5- compatible versions of this project, all strings were embedded in the assembly itself, so the framework didn't even look for them anywhere except MyAssembly.dll. How can I make it look at the assembly and not look at anything else?
Second, I noticed a .resource file in the project's bin\Debug directory, but it's named MyAssembly.Properties.Resources.resources, not MyAssembly.resources, and msbuild doesn't copy it to bin\Debug or anywhere else where MyAssembly is referenced. Is this a useful hint to what may be going wrong here?
Third, I can open a new, empty project in Visual Studio 2010, add Resources.resx under properties, put a string there, reference it in the code as TestProject.Properties.Resources.String1, build, and it works like charm. But in the old project, even readding Resource.resx with its strings doesn't help.
Can you explain why .NET 4.0 compiles these string into one place and then looks for them in a different place, causing the FileNotFoundException? And what is the proper way to migrate a .NET 3.5-compatible assembly with such embedded string resources to .NET 4.0?
Mystery solved.
.NET (before 4.0) looks for the .resource file first. If the file is not found, it looks inside the assembly to find the requested resource.
Starting with .NET 4.0, if the .resource file doesn't exist, the framework fires an AppDomain.AssemblyResolve event and passes the resource file name in place of the assembly name. (Why AssemblyResolve? - this is probably a bug.) Only if this event is not handled, does .NET 4.0 look inside the assembly for the resource.
As it happened, the application had an AssemblyResolve handler registered. The handler was programmed to locate DLLs and never failed for years until the day of the .NET 4.0 upgrade, when it was asked to locate a nonexistent resource file.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!
I using unit testing, to ensure that I can read connect string information from the ConnectStrings section of my app.config file. This works fine in the application proper, However when I attempt to generate a unit test for this under the Test Project, the dll.config file is being ignored, and the connectstring info from the machine.config file is being retrieved instead. How do I ensure that my tests read from the correct config file?
Your test project must have its own App.Config file.
You should add an app.config file to to your test project and populate it with the necessary values. You may ask "Why can't I use the existing app.config in my project?" The real answer is probably out there but personally I like it this way because it means my test project never points at my production environment.