I recently read that it is possible to define the Log4Net Config XML in defining this file in a class attribute.
<Assembly: log4net.Config.XMLConfigurator(ConfigFile:="Log4Net.Config.xml", Watch:=True)>
How can I define this file using only pure VB.Net code without using Attribute technique ?
Example (this is only textuals examples)
log4net.Config.OpenFile("Log4Net.Config.xml")
log4net.OpenConfigFile("Log4Net.Config.xml")
log4net.InitLoggingConfigFile("Log4Net.Config.xml")
The configuration's file already exists.
I search only the code that read it to configure logging.
To solve your issue, you can use XmlConfigurator.Configure() function
XmlConfigurator.Configure(new System.IO.FileInfo(args[0]));
that is explained on Apache Net4Net site
Related
How to add a configuration file while creating the vs code extension?
as in JAVA, we had activator classes through which configuration file was created.
How do approach the same in typescript and vs code???
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 have to build a .Net application that consumes a bunch of web service. This web service runs under weblogic. The WSDL of the web services mention a XSD file that describes the types.
When I try to add a "Service reference" with VS studio, I have some errors :
Warning 1 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://mycustomer/ws/types' could not be found.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://mycustomer/ws/wsdl']/wsdl:portType[#name='lbWebPT'] C:\Projects\mycustomerproject\Service References\ClientService\Reference.svcmap
X3 for the portType, Binding and port elements of the wsdl file.
I was guessing this was because of the missing types defined in the xsd file. To workaround this error, and also to avoid duplicate code, I run the following command on my xsd file (in a pre-build event command line) :
"%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\bin\xsd.exe" "$(ProjectDir)xsdofmycustomer.xsd" /namespace:"MyCustomer.WebServices.Types" /c /o:"$(ProjectDir)."
this command successfully produces a code file with the types and with the correct namespace defined in the XmlRootAttribute.
this code has been put a dedicated VS project. The project where I'm trying to reference the service reference this project. However, the error is still occurring.
What can I do to solve my problem ?
PS: I was able to partially solve my problem using svcutil.exe pathtowsdl pathtoxsd, but I'd like to be able to maintain the reference in VS for ease of use.
thx
I'm not a fan of using project Service References because of the cruft the proxy generator inserts by default. But, if you really want to use Service References for your project then you need to merge the contents of the wsdl & xsd files into a single file. The Service Reference UI assumes all the data it needs to generate the proxy is in the file you give it. SvcUtil is more flexible as you found out. You should able to replace the wsdl:import element with a wsdl:types element that contains the xsd file contents (without the xml directive of course). Next, you enter the path to the file in the address textbox of the Add Service Reference dialog and you should be good to go with Visual Studio catered proxy goodness.
I'm very new to MSpec and BDD in general and are currently having trouble having mspec pass a Search class that looks up employee data via an XML feed. The parameters for the url are held in an app.config file and seems as if the app.config is not being accessed to obtain the config setting.
Otherwise mspec is running fine for all other tests so far its just this one particular.
How do I write a test to utilise or mimic if thats needed, for the config file access please ?
Thanks
You probably have app.config in your production code project (project which is being tested), try adding the same app.config in Tests (project with MSpecs).
I have inherited a project that has class libraries written in VB.NET, some of these have ".settings" files and the others have a ".dll.config" file to store connection strings. What is the difference between these 2 methods?
EDIT: In what scenarios would I prefer one over the other?
They're basically the same thing - or strongly related, anyway. A settings file gives you strongly-typed access to entries in an app.config file, and keeps them in sync. When you compile, the app.config file is copied to the bin folder with the name of your assembly.
Note that, if you modify the .config file by hand, you can lose changes if the settings file overwrites them. In VS2008 it will prompt you, so you can choose to sync them.
I think that .settings is application wide, while the .dll.config files are specific to the assembly they are named for.
".config" files are at the core of .NET configuration system. They store the actual configuration data. In the early .NET framework, if you wanted to extend the configuration system to handle your custom configuration data, you had to do this manually. "Settings" file is a feature that allows you to visually define configuration options and use them to create a strongly typed class. This class can then be used as a method to read and manipulate the configuration data specified in application's ".config" file at runtime. They also provide some neat features automatically, such as defining per-user or per-application configuration options. They greatly reduce the hassle to manually extend the configuration system.