It looks like the DSOFramer.ocx component is not available for download anymore from MSDN as described here. Also the DSOFramer component is a 32 bit component. Given this, i have 2 questions:
Is there any other alternative for hosting a word document in a Windows Form apart from using the DSOFramer.ocx component?
If i move to Windows 64 bit operating system, and run the windows form as a native 64 bit process, then how do I host the word document in a 64 bit process?
If you compile your application as a 32 bit app, Dsoframer will continue working for you.
Go to your Project Properties under Build tab and set Platform Target to x86.
Related
I have VSTO project (excel addin) created in 32 bit machine and it was working fine. Recently we had to use 64 bit client machine to use same application, but when launching application, the content (drop down list,.. etc) of excel page become freeze.
Any suggestion to resolve this issue ?
Thanks.
We're supposed to carryout Performance Testing on a 64 bit standalone desktop application on 64 bit OS built around .Net 4.0 and HTML5 with WPF & WCF(it's a ClickOnce Application)..
While using LoadRunner 11.5 for recording, application is NOT launching in the foreground but in the background, the respective process is running in Task Manager.
We've Googled and found out that a ClickOnce Application cannot be recorded using the general installation path(E:\xxx\xxxx\xxxx.exe)
Possible workaround might be going forward with the .exe file in the Deployment Folder. But we're still unable to launch the application using VUGEN via the exe file in the DeploymentFolder path: "C:\Users\username\AppData\Local\Apps\2.0\obscure_dir_name1\obscure_dir_name1\ "
Please find the links below for further info on ClickOnce-VUGEN problem.
Recording ClickOnce Application in VUGEN
MSDN Forums on ClickOnce Application
What is the application (or presentation) layer protocol communication mechanism for this application? (see OSI model definitions for clarity on application of presentation layer protocols)
You will already have an issue regarding a 64 bit application for recording as vugen is a 32 bit application and hooking is not going to effectively cross the WOW32 subsystem barrier for the 32 bit control of a 64 bit application. See release notes regarding the recording of 64 bit applications
I have inherited a classic ASP project and a VB6 Component (ActiveX .dll) that goes with it.
I would like to be able to debug this component by running it locally on my machine.
I have a Windows 7 Home Premium (64 bit) laptop.
I have setup IIS 7.5 locally (production is running IIS5), however, when I browse to the site (locally) I get:
Active Server Pages error '00000000'
Create object failed
?
An error occured while create object 'OBJECTNAME'
Microsoft VBScript runtime error '800a01ae'
Class does't support Automation: 'ID of object in global.asa
I'm not a server guy, so I don't have a lot of experience setting up IIS. I want to setup this project locally so I can step through the COM object using the debugger.
What do I need to do to get this running?
Just as an FYI :
In the global.asa I have the following:
<object runat="server" scope="session" id="ABC" progid="prjABC.clsABC"></object>
Then in the ASP I have the following call:
if ABC.propertyName = True then
...
It fails at that line.
Sounds like the application pool your site is running in is configured for 64-bit mode (the default).
Switch it to 32-bit by right clicking on the pool and choosing Advanced Settings:
Set Enable 32-Bit Applications to True.
You might also want to configure the Managed Pipeline Mode and set that to Classic, not all Classic ASP apps are happy running in Integrated mode.
If all you need to do is debug the component it may be easier writing a COM Application that uses this COM component. Especially if you have the source to the component you can launch your test application from your vb6 component project as your debug application.
Since it's VB6 though you may have to set up a XP virtual machine to be able to run visual studio 6.0 (I've never been able to get 6.0 working on windows 7). Either that or upgrade the component to visual studio 2010.
If you want to run 32 bit components in a 64 bit environment, you can do it. The trouble with setting IIS to allow running 32 bit components as described above is that you end up having all of iis running 32 bit - which if it's a webserver means the main app you're running is 32 bit so reduces the speed advantage of a 64 bit machine.
To run a 32 bit component in a 64 bit IIS, you need to put it in Component Services. Start->Run->"comexp.msc" runs component services. Then just expand down the tree until you find COM+ Applications, and create a new empty application (with all the defaults set as are). Then expand that application and right click on components and then "new">component. The install new component and select the DLLs. This should allow a 64 bit component to just use the 32 bit ones.
I know that there are issues with the VFP OLEDB provider on 64 bit machines. ... but what issues do you encounter while actually running a VFP application - on a 64 bit machine? Has anyone had any experience in this area?
My first thought was that it would just run as a 32bit app, without making use of the 64 bit power. However, I ran into difficulties with a FoxPro application connecting to a SQL Server database (probably an OLEDB issue as well). Are there other issues as well?
This is somewhat of a specialized scenario, and it may not be related to 64 bitness, but since you asked...
My organization recently hosted a legacy VFP 7 app on a Windows Server 2008 Enterprise 64 bit server for access over Terminal Services. The app runs fine, but there is some kind of bug with the TS Easy Print technology. When you print from the app to a redirected client printer over Easy Print, the top, left, and bottom sides of each page of the document get clipped. The workaround we use is to have the users print to pdfFactory on the server first, then print from pdfFactory to the redirected client printer over Easy Print. Works great.
This is somewhat of a stab in the dark...but I believe there are some drivers with MDAC that aren't available in x64 windows. I think you may be able to install the normal 32-bit MDAC but it will install to the x86 folder.
We've seen zero problems with our VFP9 apps on 64-bit XP, Server 2003, Vista, or Server 2008.
Our print engine is a VB DLL though, so we wouldn't run into any VFP-specific printing issues.
We have a WinForms application written in C# that uses the AxAcroPDFLib.AxAcroPDF component to load and print a PDF file. Has been working without any problems in Windows XP. I have moved my development environment to Vista 64 bit and now the application will not run (on Vista 64) unless I remove the AxAcroPDF component. I get the following error when the application runs:
"System.Runtime.InteropServices.COMException:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))."
I have been advised on the Adobe Forums that the reason for the error is that they do not have a 64 bit version of the AxAcroPDF ActiveX control.
Is there some way around this problem? For example can I convert the 32bit ActiveX control to a 64bit control myself?
You can't convert Adobe's ActiveX control to 64bit yourself, but you can force your application to run in 32bit mode by setting the platform target to x86.
For instructions for your version of Visual Studio, see section 1.44 of Issues When Using Microsoft Visual Studio 2005
The .Net framework 1.1 is always targeting 32 bits CPUs while .Net framework 2.0 and above can target 32 bits or 64 bits according to the processorArchitecture property of the program manifest changed by the 'Platform Target' option of the Visual Studio IDE.
With the default option 'Any CPU', the IL code is compiled according to the platform but of course the COM call to the AxAcroPDF 32 bits component fails if the platform is 64 bits.
Just rebuild the EXE to target 32 bits platform only. This works fine with the WOW64 emulator in Vista 64 bits.
Use DLL isolation, works with every 32bit COM+ application. See more at:
http://support.microsoft.com/kb/281335
With this solution you can isolate your 32 bit COM+ application into a separate 32bit process.
64bit applications search installed COM+ objects at: HKLM\Software\Classes, but 32bit applications use HKLM\Software\WOW6432\Classes