Im using VB6 in a project and I've some .Net dlls to handle document transfers.
In one of these dlls im calling a webservice to retrieve my documents. This code works if only run as .net project, however running from vb6 it gives me the following error:
"Could not find endpoint element with name "DocServiceSoap' and contract 'documentWebService.DocServiceSoap' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element"
I've googled around and tried everything, e.g. copying from app.config to web.config, specifying endpoint name when calling for service, still no luck :/
Any ideas?
I guess your app.config is called myDotNetDll.dll.config? That's wrong. The config file always need to be attached to the executable file.
So, to solve your issue, you need to copy it to your VB6 application, i.e., it should be called myVb6Application.exe.config and located in the same directory as your myVb6Application.exe.
Related
Exception screenshot
I am pretty sure the C:/test/AdPlatform.Shared.dll is exist.
When I run this in Rider/VisoStudio, it works well.
When I try to run it as a system service, it does not work. There is no error and it creates null instance.
Adding custom Reference of Assemblies/DLL in any project will work only in Local Machine, not in other machine/Environments
ADDING THIRD PARTY DLLs IN ANY PROJECT FROM LOCAL PATH IS ALWAYS RISKER
Correct Way:
Registering the Custom DLL in GAC then Add the reference from SYSTEM PATH
For Web service/MVC Related Project(s) creating custom folders(lib) in the Solution itself and adding the DLL from that folder will be the best way to achieve it.
If you want a external library in your solution you need to place its file in a place the solution can access from anywhere (aka deploy location), meaning, put the file in a solution folder and set its using statements to its namespace anywhere you reference it in your project(s), so it will be sure to find the library you need.
I have a WSDL file on disk and loaded as a web reference. The problem is that the web reference itself is looking for the WSDL on my machine (using an absolute path), which obviously won't work on teammates' machines.
Is it possible to have the web reference look for the WSDL with a relative path, or from the Resources file? The WSDL is for a third-party service that we've modified to add some extra fields (per their recommendation).
When you add a service reference to the WSDL file on your machine, it gets copied into your "Service References" folder in your project. At that point, the API for your service is determined. There is a "Reference.svcmap" (XML) that is created that holds the location of the original location of the WSDL file. This is so that you can update the service reference in your project if the API changes. But, even without having that original WSDL file you can check in the code and your team can use it without issue. But, if you want them to be able to update the service if the API changes, then you need to actually host that WSDL file in a publicly accessible place. Usually, the web service itself provides the WSDL file and you wouldn't have it on your file system. If you plan to update and change the web service, you should connect to the WSDL hosted on a development web server. That's really where it belongs, and not a local file. But, there's no reason your local file reference wouldn't work just fine until someone tried to update it. If your web service never changes, you've got no problem. If it could change, then host it somewhere and reference a real URL.
My initial testing of tweaking the XML in Reference.svcmap file to try for relative path references did not work, but if you decide you really want to get this to work as your question describes, this is the place to make your attempt.
My suggestion would be to create a programmatic proxy using the cmd line tool wsdl.exe or svcutil.exe to create the .cs or .vb proxy that you could then add to the solution.
This allows for not needing the wsdl file at all. See more information on how here for .NET 2.0 http://msdn.microsoft.com/en-us/library/7h3ystb6(v=vs.80).aspx
for .NET 3.5 or later and svcutil look here: http://msdn.microsoft.com/en-us/library/aa751905.aspx
I am developing a C# application in Mono and trying to use log4net. The logger works just fine when I load the configuration manually however, I would like something more elegant.
In the log4net documentation it states that a config can be loaded from the assembly by using the following (or similar) line:
[assembly: log4net.Config.XmlConfigurator(ConfigFileExtension="log4net",Watch=true)]
I have ensured the config file gets moved to the build directory and has that extension. I have also made sure the AssemblyInfo.cs is marked "Application Definition" in MonoDevelop. I do not know why this is not working. Does anybody have any ideas?
BTW: I have searched all over the place trying to find an answer. I also tried loading the config from a resource and that did not want to work either.
It is possible, but awkward, to use multiple config files with log4net. See the discussion here: log4net - configure using multiple configuration files
Are you doing logging within your .exe and your .dll?
Can you make do with a single config file?
Bear in mind this section from the documentation: "if you use configuration attributes you must invoke log4net to allow it to read the attributes. A simple call to LogManager.GetLogger will cause the attributes on the calling assembly to be read and processed. Therefore it is imperative to make a logging call as early as possible during the application start-up, and certainly before any external assemblies have been loaded and invoked."
Try and distill the issue down to a simple example.
Ensure your config file is name exename.exe.log4net
Ensure that you place the AssemblyAttribute you have in the quesion, into the AssemblyInfo.cs of your .exe
Ensure that you make a call to LogManager.GetLogger ASAP in your .exe, before invoking any code from your .DLL
I have a WCF Service and Client DLL which has the proxy class for my WCF Service. My client dll is going run by a different exe. I have restrictions in adding my client app.config file to the exe location. I cannot do this myExe.exe.config. I want to load the client app.config file in the client dll itself or the app.config file should be loaded from a different location.
And my exe is C++.
Is there any way to do this?
To explicitly load a particular config, you need to launch the object in a separate AppDomain. Use one of the AppDomain.CreateDomain overloads that takes an AppDomainSetup where you can pass in the path to the config file. Yout need to make sure any return values can be marshalled across AppDomain boundaries. No, there isn't an easier way to do this that I am aware of.
This is actually a standard issue with .NET. In general, when you create a separate project which will build into a dll, you can create settings in an app.config file. These settings are not automatically made part of the web.config of the application which uses the DLL.
The "solution" has always been: copy and paste from your library's app.config and paste into the app.config or web.config of the consuming application.
This actually makes a certain amount of sense: these configuration settings are meant to be changed based on the environment in which the code is executing. One set of configuration for your WCF client, stored in a single location, brings us back to the days of the registry.
While using a third party dll I was getting the following exception:
exePath must be specified when not running inside a stand alone exe
with the following trace
System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath).
The reason I found was that it was looking for app.config and I had provided the details in web.config. My question is: why does the system.configuration differentiate between web.config and app.config? Any thoughts?
Executables:
Several .NET executables can live in the same directory. As there cannot be two files with the same name in the same directory, the applications must use different names for their main configuration files. The applicationName.exe.config scheme solves this.
Web applications / sites:
.NET web applications are compiled to DLLs, and web sites are usually compiled just-in-time. Hence, there is no "main entry point" in these types of projects. It is possible to create a web project where each page is compiled to its own assembly. Which one is the main assembly? Which assembly should we name the configuration file after?
Fortunately, only one web project can be hosted from a single directory, so only one main configuration file is going to live here. This allows for the main configuration file name to be picked by convention, and that file name happens to be web.config.
web.config is for your website and web applications only. It stays fixed, i.e. doesn't change its name; it's always called web.config.
app.config is for non-web applications - Winforms, WPF, NT Services etc. This will be renamed into YourApplicationName.exe.config when you build your project. You won't ever find an app.config by that name in an application's directory (or if you do, it will not be used).
Why Microsoft choose to use two different kind of names - I don't know - ask Microsoft.
So you basically just have to know what you're dealing with and provide the information in the correct place.