I'm trying to implement custom dotnet host in C++ by using hostfxr:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting
It works, however System.AppDomain.CurrentDomain is not initialized correctly.
For example, AppDomain.CurrentDomain.BaseDirectory is empty.
Is it possible to configure the default AppDomain by using only nethost.h and hostfxr.h headers or should I rather go deeper and try to touch coreclr.dll API?
I found it.
The following coreclr runtime property must be set:
hostfxr_set_runtime_property_value(ctx, L"APP_CONTEXT_BASE_DIRECTORY", L"path\\to\\application");
This way AppDomain.CurrentDomain.BaseDirectory is getting initialized.
Related
.NET 3.1 App was working fine before but today after I tried to run it through IIS, it is giving me this error.
given messsage error
browser shuts down after this
This is how event viewer looks
and also I noticed something, I'm not sure if it is important, in applicationhost.config there are lines about .Core2 (I'm using .Core 3.1)
I solved it by creating a new project and copying everything (except Program.cs and Startup) in it with some necessary configurations in Startup.cs like ConnectionString and Mapping
You could have also enabled the startup errors logging.
That way you would know what went wrong for the next time.
EDIT: I found a way to get it to work locally, but on Azure I still get System.IO.FileNotFoundException on that assembly.
My question might seem like a duplicate to this question here. But it is slightly different, I have already tried that solution and it did not work. Here are the details.
I have an ASP.NET MVC App that has a Reference added to a third party CLR DLL. That third-party DLL requires a native DLL which it invokes. Now if I had control over where the Shadow Copying occurs and what is copied, I would be in paradise. The Shadow Copying misses copying that native DLL despite it's Build Action set as Content and Copy To Output Dir set as Copy Always.
So I searched internet and ran into this discussion on SO, which is same as what was mentioned earlier. I tried adding the code that sets the PATH Environment Variable inside Application_Init and Application_Start of Global.asax, I set the breakpoints in both the methods and to my surprise I get the ASP.NET Error Page before it even hits the breakpoint. This leads me to believe that the referenced assembly at the time of binding hits the native DLL and invokes it. What can I do? Can I delay the reference binding somehow?
EDIT: Yes we can, I opened the Referenced DLL's code which was written in Managed C++, I adjusted the linker setting to Delay Load the Native DLL and now my Application_Start executes first. Yayy! but that does not solve the same problem I am having on Azure
Here is the test solution with DLLs
Here is the source code for the Native DLL
Here is the source code for the Referenced Assembly that uses the Native DLL
To download the Native DLL distribution, Go to their distribution page, choose the windows archive with the bitness you desire (I am using 32-bit), and you will find amzi.dll inside APIs/bin directory.
Actual problem was the wrapper DLL not recognized on Azure server because of lack of support of earlier frameworks and toolsets, as well as Debug CRT.
I used XDT/Application_Start to set the PATH environment variable to include the location of my native DLL
I upgraded my Managed C++ Wrapper DLL to use Toolset 14.0 and .NET 4.6.2
Used Linker Setting of /DELAYLOAD on Managed C++ Wrapper DLL
After downloaded the DLLs and source code which you provided, I found that the native DLL depends on x64 platform. Firstly, we need to change the Platform property of our web app to x64 using Azure portal. If the platform button is disabled, you need to scale up your web app plan to Basic level plan or higher level.
In addition, the original path may end with “;”, so we need to check whether it contains “;” and append right content to it. Code below is for your reference.
string path = Environment.GetEnvironmentVariable("PATH");
Trace.TraceError(path);
string binDir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Bin");
Trace.TraceError(binDir);
if (path.EndsWith(";"))
{
Environment.SetEnvironmentVariable("PATH", path + binDir);
}
else
{
Environment.SetEnvironmentVariable("PATH", path + ";" + binDir);
}
To test whether the path is set successfully, you could add a page to test it.
public ActionResult GetPath()
{
string path = Environment.GetEnvironmentVariable("PATH");
return Content(path);
}
After path is set, the native DLL can be load successfully on my side.
On my end I added a throw new ApplicationException("Test") at the beginning of Application_Start and instead of getting my test exception, I was getting the DLL load error.
It means the setting path code will not executed. To fix it, you could remove the native DLL reference from your web application. Now your application could work fine and set the path environment variable. Then you could add the native DLL reference back.
Another way to do it is that we could create a webjobs and set the path environment variable in webjobs and deploy this webjobs before deploying your web application.
I am using 32-bit distributions, my native dlls depends on x86/32-bit.
If you use 32-bit distributions and the platform targets of your CLR DLL and your web application are set to "x86 or Any CPU", you won't need to change platform to x64 in web app. Please change it back to x86.
I'm fairly new to Flex\AS3
I'm using flash builder 4.5 for php and I'm trying to connect to my DB via remote objects.
I'm following adobes instructions as listed here:
http://help.adobe.com/en_US/flex/accessingdata/WSbde04e3d3e6474c4-668f02f4120d422cf08-7ffe.html#WSbde04e3d3e6474c4-668f02f4120d422cf08-7ffa
I've created the php service, and successfully finished the wizard.
I've tested my service with the Test tool and it is indeed returning my results.
My problem is that it seems that flash builder didn't create the service's files(super+base) at all. For example, when I drag the service into a dropdown component I get an error saying that the service component can't be found.
Does anyone know this issue happens? how can the test tool work if the service classes don't exist?
Thanks in advance,
Ravid
The problem was that I didn't checkout the files before using the wizard so flash builder didn't have write permissions on the files and therefore didn't create the necessary files.
once he had the write permissions - everything worked just fine
I am using a COM dll in my .Net web application. This works fine on multiple different machines.
However on one particular machine I get the following error:
Unable to cast COM object of type 'CServer.CApplicationClass' to interface type 'CServer.ICApplication'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE} ' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
I have registerd the dll using the regsvr32 command.
I have also created a COM+ application for this dll.
Running a search through the registry
I can find the key in numerous places.
I have also tried unregistering the dll and deleting all referneces on the computer to this dll. And afterwards re-adding the dll and re-registering it.
I have written a simple windows script file which tests the dll. This works fine. However the problem exists in my .net project which is running in iis.
Can anyone help me with this?..
If you need anymore info please leave a comment. Thanks.
I had a similar problem, with the "TYPE_E_CANTLOADLIBRARY" message.
Background:
I had a project which used Interop.ReferenceA.dll. This file was created using tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll.
Solution:
When I took a look at ReferenceA.dll using RegDllView I noticed that ReferenceA.dll had a subclass, which was the IID shown in the error message.
I looked around in the source code of the subclass and noticed that it had a dependency to Interop.ReferenceB.dll.
Turns out that the subclass needed Interop.ReferenceB as a type-library to work. So I ran this:
regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll (the 32-bit version of regasm was used.)
And the error went away.
Make sure your AppPool is set to x86. Also make sure your assembly is targeting only x86.
I was having a similar issue. First got Access Denied, which after some looking around was resolved, only to be faced with this error message (TYPE_E_CANTLOADLIBRARY). Mind that I'm running a COM+ Component on Windows 7.
After some fruitless attempts which involved messing with the registry, my workmate and I found a way of getting it up and running:
1) Unregister your dll (regsvr32 -u dllname)
2) make sure your references to the dll are cleared up from registry (backup first)
3) Create an empty com+ application (server app) in Component Services
4) Copy the application id to the clipboard
5) go to "c:\program files (x86)\Complus applications" and create a folder with the id on your clipboard
6) copy your dll into that folder and register it
7) Go back to your Component Services and add the component to the app you created using the dll on "c:\program files (x86)\Complus applications{*app id*}"
that did it for me. Hope it helps.
I had a similar problem where the error was triggered on my PC but not on that of other developers.
It turns out that I had been testing an automatic build process on my PC that had updated the version number of the assembly, thus registering the TLB in the registry with a version number higher than the one we were normally using.
When trying to get the interface, the server was consistently using the wrong TLB information leading to the wrong assembly. Once I deleted the higher version entry in the registry, it worked fine.
Now we just have to ensure the build process is not going to cause that issue again. :)
I have a WPF application in VS 2008 with some web service references. For varying reasons (max message size, authentication methods) I need to manually define a number of settings in the WPF client's app.config for the service bindings.
Unfortunately, this means that when I update the service references in the project we end up with a mess - multiple bindings and endpoints. Visual Studio creates new bindings and endpoints with a numeric suffix (ie "Service1" as a duplicate of "Service"), resulting in an invalid configuration as there may only be a single binding per service reference in a project.
This is easy to duplicate - just create a simple "Hello World" ASP.Net web service and WPF application in a solution, change the maxBufferSize and maxReceivedMessageSize in the app.config binding and then update the service reference.
At the moment we are working around this by simply undoing checkout on the app.config after updating the references but I can't help but think there must be a better way!
Also, the settings we need to manually change are:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
and:
<binding maxBufferSize="655360" maxReceivedMessageSize="655360" />
We use a service factory class so if these settings are somehow able to be set programmatically that would work, although the properties don't seem to be exposed.
Create a .Bat file which uses svcutil, for proxygeneration, that has the settings that is right for your project. It's fairly easy. Clicking on the batfile, to generate new proxyfiles whenever the interface have been changed is easy.
The batch can then later be used in automated builds. Then you only need to set up the app.config (or web.config) once. We generally separate the different configs for different environments, such as dev, test prod.
Example (watch out for linebreaks):
REM generate meta data
call "SVCUTIL.EXE" /t:metadata "MyProject.dll" /reference:"MyReference.dll"
REM making sure the file is writable
attrib -r "MyServiceProxy.cs"
REM create new proxy file
call "SVCUTIL.EXE" /t:code *.wsdl *.xsd /serializable /serializer:Auto /collectionType:System.Collections.Generic.List`1 /out:"MyServiceProxy.cs" /namespace:*,MY.Name.Space /reference:"MyReference.dll"
:)
//W
Rather than changing the generated endpoint, uou could add a second endpoint and binding definition with the configuration you need, then in your code just put the name of the new endpoint in your service client constructor.
Somehow I prefer using svcutil.exe directly than to use the "Add Service Reference" feature of Visual Studio :P This is what we're doing on our WCF projects.
I take your point, svcutil is definetly the more advanced way of adding and updating service references. Its just a fair bit more manual work when "right click, update reference" is so close to just working in a single step.
I guess we could create some batch files or something to just output the reference code. Even then, manually checking out and updating the service code with svcutil will probably be more work than just undoing the check out on the config.
Thanks for the advice in any case.
What we do is we check out (from source control) the app.config and *.cs files that are autogenerated by the svcutil.exe utility, then we run a batch file that runs svcutil.exe to retrieve the service metadata. When it's done, we recompile the code, make sure it works, then check the updated app.config and *.cs files back in. It's a whole lot more reliable than using the oft-buggy "Add Service Reference" with Visual Studio.