Hopped in the way back machine today

Got an email from a long-time customer who had stopped updating their system with version 7.0 and were still running the Pervasive database.  She’s the only user and when her machine froze she had to delete the activity.btr file to clear her user.  Unfortunately in a momentary lapse she deleted the entire system directory.  This also coincided with her server having not had a successful backup for a few weeks.  We gave the tapes she had a try but it appears the drive is having issues, so restoring wasn’t an option.  Luckily she did still have her version 7.0 cds so I was able to reinstall Dynamics 7.0, create her user and companies and then copy the data directories in to the new install.  Made for a fun challenge to start the day, and hopefully this will provide some motivation to update her old hardware and software to a more recent vintage.

Talking about Installing Dynamics GP 10.0 with .Net 2.0 SP1

Saving this post from another Andy regarding install issue with GP 10.0 and .Net framework 2.0 SP1. - Good Stuff! 

Quote

Installing Dynamics GP 10.0 with .Net 2.0 SP1

Workaround for Dynamics GP install on 64-bit Windows

I ran into an issue when installing GP 9.0 on a couple of brand-new servers with 64-bit Server 2003 on them.  The servers will be used for Citrix, so they need to have an install identical to the rest of the GP clients for everything to function consistently.  However installing the 32-bit Dynamics GP application on 64-bit Windows results in the client folder ending up in C:\Program Files(x86)\Microsoft Dynamics\GP.  We have a ton of VBA code with references to files in the default client location, which didn't want to function.  To redirect those references would require our developers to keep two separate code libraries.  In addition the home page didn't seem to function correctly, as it was missing the headers for each of the sections, as pictured here.  The home page seemed to have an issue with the (x86) in the path, because as soon as I installed GP9 outside of C:\Program Files(x86), it worked fine.

After working with support at Microsoft, who seemed puzzled as to why it was installing in C:\Program Files(x86), which appears to be standard behavior when installing a 32-bit app on 64-bit Windows, we ended up coming up with a work-around.  We installed GP 9 to C:\Microsoft Dynamics\GP, then created an empty C:\Program Files\Microsoft Dynamics\GP folder.  Then we created a junction point, which redirected the empty C:\Program Files\Microsoft Dynamics\GP folder to C:\Microsoft Dynamics\GP.  All of the vba code now functions correctly and the home page seems to be happy as long as it's not installed to C:\Program Files(x86). 

Issue installing GP10 with .Net Framework 2.0 SP1

Installing Great Plains Version 10 on .Net Framework 2.0 SP1

By Jivtesh Singh

I read in the newsgroups about this and didn't believe it, till I ran into the issue today.

If you try and install GP 10 on a machine that has .Net 2.0 SP1, the installer would fail. It installs just fine on machines that have .Net 2.0.

Patrick from MSFT Developer support wrote -

I actually ran the install of GP 10.0 and sometime during it I get the error
as well.  So something in the install yet again is checking incorrectly.  I
don't see how development is going to resolve this unless they rebuild the
installs for 10.0 RTM and 10.0 SP1.

I ended up uninstalling .Net framework 2.0 SP1 from the machine and then installing .Net 2.0. I had this luxury with the machine being a new machine, but this would be impossible in most cases. What complicates matters is the fact - that .Net 3.0 requires .Net 2.0 SP1 to be installed. And you can't uninstall .Net 2.0 SP1 if you don't uninstall .Net 3.0. Phew!

There is no knowledgebase article or hotfix about this yet.

However, I just read that if you open a support case with Microsoft - " There is a transform file you can use to install both the Dexterity Shared Components and another one to install Dynamics with. Because this is an issue with our install, the case shouldn't be chargeable unless you have other issues outside this scope. "

I am very interested in knowing how Microsoft resolves this in the long run. Would they release a new setup file ? Will they send out this information to partners ?

I kind of sympathize with them, because I know it can be a pain testing against all versions of frameworks. Windows update would install .Net 2.0 SP1 on most machines, so this probably something we need to be aware of.