I have just migrated ASP website and COM+ component from old server to new 64 bit win 2012 server. But One of the functionality where we upload the file onto the server has become very slow. We have used SoftArtison's FileUp assembly.
Same website and component deployed on winxp takes 1 minute to upload the file, and on win 2012 64 bit server about 20 minutes. On winxp FileUp assembly used is older version.
I have just ran out of ideas as on what to do and what could be cause.
Thanks. But the issue was not related to SoftArtisans FileUp. The issue was regarding the COM+ VB component. Actually I have found the root cause. There was high level string manipulation (split, substring, trim, append, concat) happening while generation of XML and VB does not have StringBuilder, so this was using up lot of memory and consuming time as well. I have moved the XML generation logic to .Net Comvisible dll, deploying the same in GAC and calling dll from VB code. And it is working very quickly now.
Related
First, don't be hatn'. I know people born when MS stopped supporting Access 95 are now in high school. I am trying to provide a path forward.
I have a WCF being developed on my Win 8.1 64 bit computer (VS 2013). When my unit test makes the call, the WCF it needs to query the DB and return a dataset. I do this using traditional dataAdapter.fill() call. This causes a 'Microsoft.jet.OLEDB.4.0' provider is not registered on local the machine.' error. I have found several posts on this forum that state the 4.0 driver will not work in a 64 bit application. So I have set the solution platform to 'x86', in the project properties i set the platform to 'Active (x86)'. When I set the platform Target to 'x86' and try to run I receive another error 'system BadImageFormatException....' so I had to switch it back to 'Any'. The error persists.
Next I thought VS web service host was run 64 bit. I installed IIS on my local dev machine and setup the project there and set the App Pool to enable 32 bit application = true, no change. Then I tried moving the dlls to sysWOW64 and register them there, still no luck. I tried to set corflags with '/32bit+' parameter, only to learn the file has no headers, so it can't be set. Finally, I upgraded to the ver. 12 driver and changed to connection string only to get an almost identical error, 'Microsoft.ACE.OLEDB.12.0' provider is not registered on local the machine.'
I am open to any suggestions at this point. I probably missed some small detail back at the beginning of all this. Thank you in advance for your help.
Started a new job where I'm working on all sorts of legacy apps - I came across one which is a VB6 (not .net) one. Its using Adobes old FDFtoolkit (again, not the one found at fdftoolkit.net) which can only be registered on a server.
Problem is, sometime over the past few years the FDF to PDF converter stopped working.
My issue, I'm pretty sure its a .dll issue - on the server FDFTK.dll and FDFACX.dll are in the Windows/SysWOW64 folder.
I don't know if their location is incoherent with where the legacy application is looking. When I'm in Visual Basic 6 (the IDE) it looks for references in the Windows\system32 folder.
Any thoughts? I ask because I don't have direct access to the server so its slow going to 'guess and check' lots of options.
EDIT: Also the server holding the .dll is a windows server 2003 (however the server passing it the fdf is a windows server 2008)
Its like a puzzle!
On 64 bit systems Windows secretly redirects calls of 32 bit programs from system32 to syswow64.
VB6 is 32 bit, everything needs to be 32 bit.
The only thing you can really do is reregister the dll. Most but not all com dlls self register.
Note using 32 bit tools.
c:\windows\syswow64\regsvr32 c:\windows\syswow64\dllname.dll
My website application uses C# COM+ components running under a particular identity to access SQL Server, invoked from classic ASP.
There's also a web service that utilises a \bin DLL in the website application that contains a method to insert some data into the SQL Server database (let's call it MyApp.Database.dll).
From the website front end, I want to be able to provide authenticated users with this same functionality.
I don't want to duplicate code in MyApp.Database.dll within the COM+ component for obvious reasons.
My idea was to utilise the COM+ component from ASP to invoke the MyApp.Database.dll method to access the SQL database using the application credential since the ASP is running as the user and has no access to SQL Server.
Problem I've seem to run into is that although I can reference MyApp.Database.dll in my COM+ component project (under 'References' and 'using MyApp.Database.dll'), when it comes to actually running or debugging the COM+ component, when it tries to invoke the method from MyApp.Database.dll, it tells me 'Could not load files or assembly 'MyApp.Database, Version=3.3.3.11658, Culture=neutral, PublicKeyToken=.....' or one of its dependencies.'
The MyApp.Database.dll is not registered in GAC (trying to avoid this, it's also used by other applications as well), and hasn't had its codebase registered in the registry using regasm (I tried this and still didn't work). The version is correct, and I've placed MyApp.Database.dll in the application folder of the COM+ component.
Am I missing something or is it not possible to do this?
Thanks in advance for your help.
This is a common mistaken expectation: just because your .NET COM DLL was found in some given folder (the folder set by the /codebase argument or RegAsm) -- it doesn't mean .NET will look on that folder for anything else.
Generally speaking, it won't. Loading a .NET assemblies via COM interop is a special case. For everything else, assemblies will be loaded in the AppDomain based on the Fusion binding policy for the process - which has nothing to do with where your .NET COM DLL is. The process is actually (depending on your version of IIS) either dllhost.exe, iisexpress.exe or w3wp.exe.
You have a few options.
First, the obvious solution is putting MyApp.Database.dll in the GAC, since .NET always looks there. Sometimes that's the right choice (I've done that and it works). You have declined to do so and you have your reasons; that's Ok.
Second, I believe you can change the binding policy with a web.config file. See here: http://msdn.microsoft.com/en-us/library/823z9h8w(v=vs.110).aspx. Yes, your ASP Classic project can have a web.config. Obviously it has no effect on your ASP Classic scripts, but (depending on the version of IIS), .NET and/or IIS itself use it for configuration. I'm afraid that I can't help you much with this alternative because I've never had to try it before, but you're welcome to explore that option - let me know how it goes.
Third option - my personal choice: You said this DLL is already a web service, right? Just call the functionality with a web service call from your COM DLL. That doesn't require mucking with magic folders, GAC and binding policies. Much cleaner. The only mild complication is tracking in configuration where your web service is located - and I bet you already do that for your database connection anyway, so it shouldn't be hard to add.
If you are curious to know where .NET is looking for the DLL, read up on these guys:
How to enable assembly bind failure logging (Fusion) in .NET
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
http://www.hanselman.com/blog/MoreOnAssemblyBindingStrongNamingTheGACPublisherPolicyAndDynamicallyLoadedAssemblies.aspx
Good luck, and please let us know what worked for you.
I have a very strange issue that i cannot figure out.
First i have a WCF service 4.0 done in VS2010.
the service have couple methods that return string array, datatable and such.
some of them use function from C++ dll throught [dllimport]
i made a test console to test everything. when i run the WCF from visual studio and use the generated path it works wonderfully.
now here is where it become strange. if i open my local IIS create a new application and point to my VS source code the WCF i can see it perfectly.
now using the http path from IIS local instead i refresh the methods all seems correct. But when i run my test app i can call any unction without any problem EXCEPT anyone using DLLIMPORT functions. they ALL crash and cannot trace even by tracing CES exceptions.
Doing line by line logging show that the exception is really on the call of those functions
the DLL in question is the same and the path is hardcoded for my computer since still in test phase and the folder is c:\DLL\mylib.DLL so nothing to do with shadow copy IIS/visual studio do when you actually run. also DLL reference by name withotu path even if it's in sys32 doesnt work.
Any clue ?
also. 32bit, changing app pool level right access on folder, full admin on machine already too. all tried but unsuccessful.
Edit: adding to all that since i haven't made this clear, it's not my first WCF real setup. i've already made alot of services before and deployed them myself (probably somewhere around 50-60 services). I am asking because i have never seen this issue before and i tried all tricks i knew and could find on the internet and resource people i know.
We have decided to incorporate the whole service in the WPF project locally since it work as long as IIS is not hosting. but this is really not a good thing as this data and work should NOT be done on client side but instead on server side. Right now it's fine since the software that need to use this is not released to public yet so it isn't critical.
Next option will be net TCP/IP windows service hosted on the web server if i don't find anything else.
We decided to go trough the trouble of having to hard code the logic in the main software and get away from web services for this issue. we will have to deal with updating, installing unregister and re register unmanaged DLL by hand somehow but at least it works.
we have added over 5 web services since that happen and no problem with them but again none of them use DLL imports.
i've created a little activeX dll under vb6 which i'm running under classic asp.
my question:
once the dll is compiled it has write-protection caused by the IIS (access denied).
i have to completely stop the webserver, then recompile + restart the server again.
is there a more convenient way to do this? maybe even without having to compile?
thx
No there isn't more convenient way. Once the DLL is loaded into memory by IIS it is locked and cannot be modified. You could write a simple VB script client in order to test the ActiveX without passing by IIS.