I am struggling with an issue and am utterly lost as to the correct approach to handle the problem.
I have an MVC 5 application running on Windows Server 2008 R2 that communicates with an accounting package (Exchequer) via an unmanaged COM dll. As I understand it (and I'm not sure I do) the unmanaged dll is created once per app domain? Meaning that multiple users of the app will all be 'using' the same unmanaged instance? Ideally, I would want one instance of the COM dll to be created and destroyed per user. Can anyone please tell me if this is possible and, if so, how I would go about implementing it? Thanks
Related
I'm currently working on a .NET 5.0 Blazor Server project that imports and utilizes user-uploaded .NET assemblies (in either DLL or NUPKG form). Currently, these assemblies are loaded using Collectible AssemblyLoadContexts which, if I understand correctly, is a major security hazard for both my user-base and the server itself. That said, I'm searching for methods that can sandbox the inclusion/execution of those assemblies. The main concerns that I can think of are:
Access to sensitive system information/environment variables
Access to processes
Access to internet (sockets/clients)
File System access
but I probably haven't thought about a plethora of other factors I should be aware of.
How could I achieve such feat?
ps: The server runs on a Linux machine and all uploaded assemblies must be valid architecture-irrelevant .net5 or .netStandard2.0 in order to be loaded.
I'm designing a new architecture in Azure. It's a multi-tenant SaaS application with an ASP.NET MVC front end and some application specific data in blob storage. I need to perform some background processing on this application data at certain points. This is currently only possible using some legacy C++ code (I can't realistically rewrite this in C#).
One thought I had was to push any background jobs onto a queue and use Azure functions to service the queue as and when a job gets pushed onto it. The sticking point is the native code. I can certainly expose methods in the native code that C# can p/invoke, but can Azure functions call onto native DLLs and if so is this a sensible approach?
The code does run in a sandbox, but this approach should work. (you may want to consider exposing the relevant API in a managed assembly that would in turn be consumed by your function).
Whether you'll run into limitations with the sandbox is dependent on what your code is doing, but you can learn more about the sandbox and its restrictions here: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
I hope this helps!
mfcu100.dll likely depends on some other DLL inside the VC++ 2010 Redist
Most probably msvcr100.dll and msvcp100.dll.
If you include all the dependency DLLs along with your native binary, it should work.
I have two ocx files which i registered on my computer using regsvr32. I use them in my visual studio project by adding a reference to the COM objects, to the project.
The problem is that when I attempt to add these to a SharePoint project, when I attempt to invoke the COM object, I get the error:
"Could not load file or assembly 'Interop.TsSDKActiveX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=60b2ad56e2b9ec22' or one of its dependencies. The system cannot find the file specified."
How can I work around this? TsSDKActiveX does not exist in the GAC (but in my Program Riles (x86), which is why I assume it is not finding it. Also, I suspect the fact that sharepoint likes 64 bit DLLs is a problem.
I tried to isolate the code in a separate application and invoked it through a WCF service, but this has been giving some problem due to how this COM component works. I need to eliminate the service.
Any suggestions on how to proceed?
You cannot load 32-bit DLLs into 64-bit process, even through COM. You could possibly rely on COM to communicate across process boundaries but i dont think it applies in your case.
I think your initial approach with WCF is most natural one. Expose a thin WCF endpoint that wraps the interface for the COM wrapper object in managed code and then interact with it from SharePoint using standard WCF client API. Now, if you must have state in your interaction, create a business object within sharepoint process that maintains and only makes calls to WCF as needed. What was your reason to abandon the WCF?
I have a DLL (written in C) that uses static thread local storage (__declspec(thread)), and I want to use this DLL from a Visual Basic graphic interface.
Unfortunately, when running the interface on Windows XP that DLL which use static thread local storage crashes when it try to acess its thread variables.
How can I solve this problem?
Thanks,
Regards
G.B.
PS
I would like to not modify the DLL.
This is a known limitation of static TLS. Although you aren't explicitly calling LoadLibrary(), the VB runtime does so on your behalf.
Note that this limitation has been lifted from Vista. The most comprehensive reference that I know of is on Ken Johnson's blog.
You may be able to get around the problem if you could get the DLL included in the imports table of the generated .exe, which would likely involve some PE hacking and I'm far from certain it's a viable strategy. Otherwise you'll need to change the DLL.
I have a web application that sometimes just hangs over heavy load. To make it come back I have to kill the "dllhost.exe" process. Does someone know what to do?
This is an Classic ASP (VBScript) app with lots of COM+ objects.
The server has the following configuration:
Intel Core 2 Duo 2.2 GHz / 4 GB RAM
Windows Server 2003 Web Edition SP2
IIS 6.0
There is some errors in the event log related to the COM objects. But why errors in the COM objects would crash the whole server?
The COM objects are PowerBuilder objects deployed as COM objects.
Is IIS 7.0 (much) more stable than IIS 6.0?
Sounds like dodgy COM objects causing the problem .. do you load them into the "Application", if you do then are they threadsafe; or are they used and discarded on each request?
Yes, recycling every few hours would help 'hide' the problem, but they ought to be debugged and fixed properly ... have you tried divide/conquer to discover which COM object is the problem ... I can imagine this is tricky on a production environment so you need to set up some heavy automated tests to reproduce the problem locally then you can do something about it.
You have a memory leak :)
This blog entry is my bible for IIS troubleshooting:
http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx
If you can't audit your code and find where the reference leaks are, an alternative is to recycle the application by restarting IIS every 24 hours or so. You can just setup a commandline script as a server job to do this.
There is probably some errors in your eventlog under the Application and System categories. Try to find the origin of these errors or post them here we'll see what we can do :)
Edit :
#Daniel Silveira
A memory leak is probable. What COM+ object do you use? I had some issues with Excel with an application I support.