StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » x64 Development Environment

RE: x64 Development Environment

Edhy Rijo — Tue, 21 Jan 2014 22:40:38 GMT

Hi Larry,

Weird, I have Win8.1 Pro x64 and did not have that issue with v1.7.7.1, the problem I had related to the DDT was that my version of the SQL Management Objects 2008 R2 (SMO) were not the ones expected to be used by the DDT SMO version 10.50.2500.0, after a long time searching the web I finally found the official site to download this specific version, I also need them for my own distribution setup or my Data Migration class will also fail when my customer try to update their database.

Here is the link for the SMO version 10.50.2500.0 http://www.microsoft.com/en-us/download/details.aspx?id=26728

x64 Development Environment

Guillermo Vilas — Tue, 21 Jan 2014 22:40:38 GMT

Hi
The workstation I mostly develop is a AMD X64 with Win XP x64 Pro, by default all x86 application will install under C:\Program Files (x86)\ path. So for example if I try to add the security tables to a project under DDT I will get an exception stating that "The package file C:\Program Files\Common Files\MicroFour\StrataFrame\Security.pkg could not be extracted because it can not be found".

The problem is at libraries level I think, maybe the path is hardcoded.

The issue is solved copying all the content of the "Program Files (x86)\Common Files" into "Program Files\Common Files"

I believe this issue needs to be evaluated by the development team to add the features to fully support x64 installations.

RE: x64 Development Environment

Larry Caylor — Tue, 21 Jan 2014 16:50:02 GMT

This is still happening. I had the same issue after installing v 1.7.7.1 on Windows 7 64-Bit. Fortunately it only took a single search to find the work around on the forum.

RE: x64 Development Environment

StrataFrame Team — Thu, 11 Jan 2007 11:53:53 GMT

Yes, thanks for the heads up... we haven't tested our installation on an x64 machine, yet. We are using the System.Environment.GetSpecialFolder() method (I think that's the name of it), however, it looks like our install is not placing the files in the same location as the path returned from that method.