we're migrating certain COM+ components from VB6.0 to C#.Net. I'm facing some challenges regarding the conversion of code (rewriting), one thing is this particular COM+ component will be consumed by multiple classic asp applications, these applications either pass ADODB Recordset as input parameter and also accept it as an output parameter. after developing a piece of code and testing it locally on 32 bit machine I'm able to build the connectionstring and also pass and accept Recordset. but when I migrate to code to windows 2012 R2 64 bit server. I see error when I try to create the object of the DLL.
So my question is it possible to use Recordset and expose it through COM+ on 64 bit machine?
Related
I am working with an ASP.NET web application written in C# deployed to IIS/Windows Server 2008 R2. The application uses NHibernate to interact with an Oracle database running on a networked unix server.
It seems that writes being made by the application to the database have no effect.
If I manually edit the value of a record in the Oracle database, the new value is reflected by the application. However, if I attempt to change a value using the application’s custom “save” functionality, the changes are not reflected in the database. It seems like reads are succeeding, but writes are failing.
Why do writes seem to be failing?
More information:
No obvious error messages are received (ie. the application does not throw an exception and it seems to continue running as if everything is fine).
Another instance of this application is running on IIS/Windows Server 2003. This instance can write to the Oracle database (ie. the changes can immediately be seen in the database by using a database viewer after clicking “save”).
The code is virtually identical between the 2003/2008 applications. However, on the 2008 server, I am using newer versions of Oracle libraries and I changed to target architecture of the visual studio projects from ‘Any CPU’ to ‘x86’ (the 2008 server is 64-bit while the 2003 server is 32-bit).
Disclaimer:
I have very limited experience working with IIS, NHibernate, Oracle databases, Windows Server 2003, and Windows Server 2008 R2. I do, however, have slightly more experience working with C#, ASP.NET web applications, Visual Studio, and MSSQL databases).
I solved it.
It turns out one of the HttpModules was not being initialized. This was because the web.config file was tuned to IIS6, and the application was running in an application pool set to Integrated Pipeline mode on IIS7. Switching the application pool to Classic mode essentially enabled backwards compatibility.
Anyways, here is the resource that helped me figure it out: httpModules not working on iis7
I have an asp.net 4.0 project that uses a combination of Bouncy Castle and the .Net framework to create an X509 certificate.
It runs properly on my W7 dev machine but when installed on W2008 (32 bit, not r2) this bit of code:
CX509CertificateRequestPkcs10 csr = new CX509CertificateRequestPkcs10();
throws this exception:
Unable to cast COM object of type 'System.__ComObject' to interface type 'CERTENROLLLib.CX509CertificateRequestPkcs10'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{728AB35B-217D-11DA-B2A4-000E7BBB2B09}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
Initially I thought it might be a 64-bit server issue since COM is only 32-bit compatible but the server is 32 bit.
The app is built using Framework 4.0 and the IIS AppPool assigned is running 4.0, Integrated mode, with an Identity of "Network Service" - all exactly as on my dev machine, as the the client browser used (IE8 32).
Does W2008-32 (Standard) not implement CERTENROLLLib out of the box? Does anyone know how to make it behave in this circumstance?
Thanks for any suggestions!
When you instantiate CX509CertificateRequestPkcs10 object specify explicitly what interface you want to use (by ProgID). In Win2008 R2 Microsoft overwrote the interface.
Instead of:
CX509CertificateRequestPkcs10 objPkcs10 = new CX509CertificateRequestPkcs10();
use:
IX509CertificateRequestPkcs10 objPkcs10 = (IX509CertificateRequestPkcs10)Activator.CreateInstance(Type.GetTypeFromProgID("X509Enrollment.CX509CertificateRequestPkcs10"));
Since in Win2008 R2 Microsoft overwrote the interface, if the code is written in Win2008 R2 the run time is looking for the new interface GUID and in regular Win2008 it can't be found because Win2008 R2 interface GUID differs from Win2008 interface Guid.
So, object can't be created, and as the result exception is thrown.
Accessing the interface by ProgID solves the issue.
See: TechNet Answer - on W2008-32 one has to specify the Interface GUID when creating the Pkcs10 object, since R2 overwrote the old "standard" interfaces.
May you help me, My ASP.NET application can't import excel file when migrating this application that run in Win Server 2003 32-bit to the Win server 2008 64-bit environment.
How to fix this bug? because in Win Server 2003 32-bit, it runs properly.
the error report that appear is:
*System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad) at Admin_ImportRisk.CreateTempTable() in C:\inetpub\wwwroot\ERMApproval\Administrator\ImportRisk.aspx.vb:line 66.*
The code in line 66 of my application is:
oBooks.Open(Server.MapPath("~/App_Data/Risk.xls"))
I have tried several scenarios:
Added Network Service user to the Microsoft Excel Application in DCOM configuration and set the identity of Application pool that in used to be same.
Added all many kind of user to the Microsoft Excel Application and My computer in security of DCOM configuration. And I have added many kind of user too in the application's folder.
Used corflags.exe to force 32-bit application to run in 64-bit environment
Used regsvr32.exe to register a Microsoft.Office.Interop.Excel.dll file to the windows 32-bit component services.
Used rundll32.exe to run the 32-bit Microsoft.Office.Interop.Excel.dll file in the 32-bit environment
But the result is still the same.
It will be a big honour if you can help me^^.
Best regards,
-imanuel-
The simple answer is to compile your project to target x86 only. This is a setting in the project settings. So the .net framework will only generate a 32 bit application at runtime, rather than defaulting to 64 bit. This is no different from setting corflags, however if you have multiple assemblies you ahve to make sure it's done for all of them. The application itself must target only 32 bit.
You're using a COM component that is 32 bit, and you can't do that in a 64 bit application, so force it to be 32 bit.
You can also force IIS to run it in the 32 bit context as documented here:
http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Also, make sure the 64 bit version of Excel is not installed on the server, but rather the 32 bit version.
Gonna need some advice for my work.
In my computer I have installed VS2010 and SQL Server 2008 Developer with a customized instance name named MYCOMPUTER. If I need to transfer the project work, that is created with ASP.NET MVC 2 and of course I also have create a database via VS2010:s interface, from my computer into another computer that has VS2010 with light version of SQL Server 2008 with a instance named SQLEXPRESS, will it be trouble?
I also heard that if you have created roles in the ASP.net via VS and it can be more error message or trouble in relation with SS 2008 Developer due to database's defined roles. Is it true?
// Fullmetalboy
It will be no troubles with moving databases if you will use backups or plain sql scripts (actually this is most painless way). As for roles - it depends on what roles are you talking about? Roles created for default SqlRoleProvider? If so all you need to do is to write appropriate connection string in your web config.
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.