An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
The type initializer for 'Trinity.Global' threw an exception.
I fixed this to change setting
Tool-Option -- Project and solution-- Web Projects--checked checkbox use the 64 bit version of IIS Express for web site and project
enter code here
And
able to Trininty Dll integrate with my WebAPI (Odata) application
Related
We have written an ActiveX application in VB 6.0 which hosts in VC++ dll. We want to debug that code using the VB classic IDE. We are unable to debug it, because it does not hit the breakpoint we have set. How do I debug an ActiveX application using the VB classic IDE?
If you start your ActiveX DLL project in the VB 6 IDE, and then create components from some other application (your C++ application, or testing it via another VB Project or any other language which can use the COM object), it should load the object in the debugger and you can set breakpoints and look at variables while running. Refer to "Testing and Debugging ActiveX Components" in the Visual Basic 6 Concepts Guide.
If that's not working for you, can you make a MCVE of the problem you're having, by creating a new simple ActiveX DLL component and calling it from a separate project (you may want to try calling it from more than one language), and reproduce the issue you're having to clarify what isn't working for you?
You probably have "Break on Unhandled Errors" selected in the IDE. If you do, then any error in your ActiveX object will set the breakpoint on the line of the client that accesses the object, typically a method call. If this is the behavior that you are getting ("does not hit the breakpoint that we have set" doesn't make this clear), then that is almost certainly the problem.
In any case, I would suggest that you check this. You should have "Break in Class Module" selected. For a full explanation of the different ways to handle breakpoints, and how to change the settings, see this post. Here also is the doc on the subject.
I am trying to migrate a legacy app that is using camel/cxf (offers some web services that include transformations) to Websphere Liberty 16.0.0.03 (IBM JRE 1.8). Tests are failing because the app uses extensions functions. I tried to disable secure processing as described here.
This change has no effect. That's why I try to switch to Saxon Implementation globally by setting System Property "javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl" in jvm.options config file. Again - this does not work.
While debugging I can see, that com.ibm.ws.webcontainer.osgi.mbeans.PluginGenerator$2 is overriding the Property with com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl during Server start. I can see a method "PluginGenerator.revertTransformerFactoryIfNeccessary" in the stack that seems to trigger the change. Afterwards all FactoryFinder.find() will return the non-Saxon implementation.
Can anyone suggest how to either disable secure-processing successfully
or
a way to successfully set a custom TransformerFactory?
BTW: It seems to me like these 2 are bugs - do I report these as regular PMR?
EDIT: possible workaround
As result of the helpful suggestions I added an '#WebListener' that will sets the System Property within the constructor (setting it in contextInitialized is too late as stylesheets seem to be compiled during application start and thus processing fails tests). I bundle this a "patch-jar" with the legacy app.
The Liberty web container plugin generator will only override the xml transformer factory if the IBM JDK is being used.
While the web container performs plugin generation using the IBM JDK, it will swap to an alternate transformer factory, and then reset to the IBM JDK default of which is com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.
I think it is worth opening a PMR here. The PluginGenerator should not assume that it started with the default xml transformer factory, and should instead save off the value of javax.xml.transform.TransformerFactory and then restore it after plugin generation has completed.
Temp workaround:
Since the PluginGenerator only swaps the XML transformer factory if you're running on the IBM JDK, you could change to an alternate JDK until your PMR gets resolved.
I agree that this is a bug. The official route for reporting problems is a PMR, but there is enough here for us to understand the problem and fix it through our beta program. If you want to get an iFix on a released version of the product (rather than waiting for it to come out via the beta program) then you will need to raise a PMR.
I have a C# app targeting Windows-10 desktop platform.The C# app calls into native component written in C++. My native C++ code has Visual C++ component extensions(C++/CX).
I am trying to run WACK test for my app & I am seeing this error:
Error Found: The general metadata correctness test detected the following errors: The overloaded method XXX in yyy.winmd have the same number of in parameters without one that has DefaultOverloadAttribute. Exactly one method overload must have DefaultOverloadAttribute
Impact if not fixed: Windows store doesnt allow apps that don't pass Windows Runtime Metadata Validation.
How to fix: Please ensure that the compiler you are using to generate your Windows Runtime types is up to date with the Windows Runtime specifications
This used to work fine with VS-2015 Update 2. I installed VS-2015 Update-3 today & from then I am seeing this failure.
The strange thing is that the overloaded method mentioned in the Error Report is not overloaded at all.
I have checked this MSDN page but couldnt find any solution.
My VS details are as follows:
MS VS Professional 2015
Version 14.0.25425.01 Update 3
MS .NET Framework
Version 4.6.01038
I couldnt find any Windows Runtime Specifications anywhere. Do I need to anything additional after installing VS Update-3 ?
This seems to be a VS compiler issue. Basically WACK tool is complaining about any user defined method name "Close"
The compiler adds an IClosable implementation whenever user defined ref class has an explicit destructor. It then maps the destructor to "IClosable::Close" method. But the compiler is not complaining about user defined method named "Close".
On further digging, I found that SQLite also seem to have similar issues. This is exactly the issue which I am hitting as well.
This is the solution employed by SQLite.
After looking at the SQLite solution, I then modified my method name from "Close" to "Closedb" and now my WACK tests pass.
As of this posting the only resolution for this issue seems like not to have a method named "Close" in your code.
TL;DR; How do I create a sandboxed AppDomain (configuring CAS) from a C++ app?
Long version:
I'm hosting the .NET CLR in a C++ app and everything is working fine... However, my AppDomain has full trust, and I'd like to have a more granular control over what it can do (i.e. configure PermissionSets, etc.) as I'll be loading unknown assemblies that could potentially cause damage.
This is the gist of it:
// Create instance (CLRCreateInstance)
// Get meta-host, CorRuntimeHost, etc.
// Start the CLR
// ...
Eventually I have everything I need to create an AppDomain (please pretend that I'm actually handling exceptions, testing the HRESULTs from each of these calls, etc...):
pCorRuntimeHost->CreateDomainSetup(&spAppDomainSetupThunk);
spAppDomainSetupThunk->QueryInterface(IID_PPV_ARGS(&spAppDomainSetup));
spAppDomainSetup->put_ApplicationBase(_bstr_t(L"C:\\PretendThisIsNotHardCoded"));
spAppDomainSetup->put_ApplicationName(appDomainName);
pCorRuntimeHost->CreateDomainEx(appDomainName, spAppDomainSetupThunk, 0, &spAppDomainThunk);
spAppDomainThunk->QueryInterface(IID_PPV_ARGS(&spAppDomain));
// AppDomain ready to go, and full trust (at least on .NET 4)
Any ideas or code samples appreciated.
We have a server application that runs as a Console Application and it has all been working great with 3.x version of XSockets. We are currently upgrading to 4.0 to benefit from the improved binary messaging.
At the moment we have everything building with the new 4.0 assemblies but can't get the server to start and are getting the following;
System.InvalidOperationException - Sequence contains no matching element
When calling...
m_xserver = XSockets.Plugin.Framework.Composable.GetExport<IXSocketServerContainer>(); <--- Exception happening here.
m_xserver.Start();
foreach (var server in m_xserver.Servers)
{
LOG.DEBUG("XSocket Server {0}", server.ConfigurationSetting.Endpoint);
}
We have checked and double check the Nuget references and compared the files in the output directory. We do have the server code in a DLL that gets called from the EXE but it all worked before moving.
If I "Continue" on the exception I get a stack over flow error after a few seconds.
In a bid to discover what (if any) DLL or Class is causing the issue I put the above code it the beginning of Mani() and commented out everything else. The app still fails in the same way. However if I start to delete the now not required DLLs from the build folder (starts with 102 files of DLL/XML/PDB) then it will start to work when I get to around 21 to 25 DLL files left. This seems very strange as I've tried to vary the deleted files as best I can and a different combination will still allow it to work at around the same number of files!!
Is there a limit to the number of files the Plugin Framework can handle?
I took a deeper look at the files causing this by copying them one by one to a known working XSockets 4.0 Console App. It turns out that a mixture of my DLLs and third party DLLs somehow make the Plugin framework crash. These are..
A number of my own custom DLLs
GalaSoft.MvvmLight.Extras.WPF45.dll
MahApps.Metro.dll
Microsoft.AspNet.SignalR.Client.dll
Microsoft.AspNet.SiganlR.Core.dll
Microsoft.Owin.dll
Microsoft.Owin.Security.dll
RazorEngine.dll
System.Net.Http.Formatting.dll
System.Web.Http.dll
System.Web.Http.SelfHost.dll
System.Windows.Interactivity.dll
Even an unmanaged DLL from Truen TVSN.dll causes the stack overflow to happen.