I have C++ project that compiles as DLL Assembly in .NET 3.5 SP1
Project is used for Image rendering processing by using WPF (it loads 2 images from local folder, applies one image on another and saves the output file in the same folder).
I want to use that that project as a reference in ASP.NET project to the rendering on the website.
So I created simple Web Project in ASP.NET C# that uses C++ project as a Reference.
Everything works great in ASP.NET Web Development Server (built-in Web server in VS2008).
But once I publish this project to IIS on the same Machine or use IIS for debug instead of built-in Web server Image rendering it's not working anymore. I'm not getting any exceptions or error messages, it just output image is not processes as it supposed to be.
If anyone know what could cause that I would really appreciate your insight!
Do you have access to the Event Logs? You should check there for any errors. You should try to throw an exception from a C#-only code path and make sure that everything is OK and regular exceptions are being thrown. Is the C++ compiled to managed code, or is native code? You might find that ASP.NET does not have the appropriate code access security permissions and needs to be registered in the GAC of the server to accessed from C#.
You should also check whether the DLL is thread-safe. This has caused issues for other users in ASP.NET/IIS.
Related
hoping someone has some insight into this issue I get pretty commonly.
I have an ASPX Web Application that is pre-compiled. I have this application running within another IIS application working flawlessly. The parent application has an "updatable=false" property within the PreCompiledapp.config.
Now I need to add more pages to my application, which I create the same way in visual studio, and publish them with the rest of the application. When I open these files to check them in notepad, I can see the "This is a marker file generated by the precompilation tool, and should not be deleted!" as well as the .compiled file that generates with it.
On a local machine and application instance, this works... but when I copy the same applicaiton build to a client (same application, same pages, same everything) it gives me the " xxx.aspx has not been pre-compiled and cannot be requested " error.
What could be some causes of this? The pages are pre-compiled so I'm wondering if this can be thrown for something else. Any help is appreciated thanks!
I think the cause may be the parent application is set with updatable=false but the ASPX Web Application which you published is allow update. So it may lead to this problem. The same error message and the cause are described in detail here.
To solve this problem is convert your application to web application(has its own AppDomain and configuration) or publish the root application as updatable as well.
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
I have two apps that use the Microsoft.ACE.OLEDB.12.0 provider to open Excel files on the same machine. One routine is a c# compiled app that works fine..the other is a non-compiled asp.net app that uses vb code behind that we are trying to re-host that throws 'The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.' errors when opening the Excel file - which appears to me to be bogus since the other app runs fine on the very same machine. I have checked the app pools for both and they appear to be set up identically...they both have 32 bit checked and are using the same .Net framework version. The web.config for both of them has the same connection string with the same options (only difference is the name of the connection)..We even re-installed the dll. I tried copying the dll to the bin folder for the aspnet app, but no luck there either. I would compile the asp.net app, except it uses ColdFusion for part of its output... I am hoping there is someone out there that has run into this particular issue and might have some pointers on where to look to solve this... Or maybe a different direction?
I have an asp.net2 WebForms project which worked fine, including referencing a dll compiled for .Net2.
Problem is that I have now recompiled the dll for .Net4 and have also 'upgraded' the VS2010 asp.net WebForms project to .Net4 and the asp.net WebForms application won't access the dll.
The first time the dll is called I get System.NullReferenceException: Object reference not set to an instance of an object.
The new dll is accessed by other WinForms applications OK.
Whatever the problem is, VS2010 freezes and I need to use Task Manager to close it down.
I've searched and can't find anything that even remotely points to what the problem might be.
The problem was in the dll's protection system. In effect, the dll was corrupted.
It is disappointing that no error events were raised to indicate a read error rather than just returning null.
I've got 4 ASP.NET DLLs and the source.
When i compile it it says its not able to run it because it's a class library. I know, but how should I run those files. I haven't got any aspx files or anything, just the 4 DLL's.
What do these DLLs do that needs to be run? Do you just need to quickly debug/test some functionality in them or something? A quick way to do that would be to just write a simple little console app and reference the DLLs in it.
You don't run an ASP.NET application like you do a normal program. It has to be hosted on a web server (either IIS, or the built-in server in Visual Studio), and then accessed by a browser, through a URL.