Here’s a problem we just figured out today. Implementing the new Sage ERP Accpac desktop Icon protocol requires that you provide a DLL with three entry points that get called when the desktop initializes.

We had all sorts of trouble getting the System Manager to load and run our DLL. We messed around with different ways to export the entry points, we implemented the DLL in a pure C environment (instead of a C++ file) and we moved the code into our activation view and exposed it there. None of it would work. So, we built a completely stand alone file and erected the basic protocol with nothing else. Presto! The DLL loaded and ran.

Cool, we didn’t really understand why, but what the hell it works. We then started adding real code to make the code do something.

Uh Oh…it’s broken again. What did we do? Well, we added calls to a dependency. Another DLL that has some support code. Why would that break it?

It turns out that when the Icon Protocol DLL is called, the working directory is NOT...

About a year ago, I posted information regarding issues with DEP (Data Execution Protection) and Accpac addins written in .Net. (http://www.zcg.com/Blog/tabid/152/EntryId/6/DEP-NET-Windows-and-Accpac.aspx) While my post addressed the issue from the point of view of running the app, there is an outstanding issue of debugging this apps. Under the default situation, debugging a .Net Accpac addin that uses Accpac controls will cause the program to fail. The underlying reason for this relates to Visual Studio's use of a hosting process to run the debuggee. This process is started by launching the VSHOST32.EXE process which then launches the debuggee. The reason this generates DEP errors is that the VSHOST32.EXE process has the NXCOMPAT flag set. This turns DEP on regardless of what is set in the debuggee process binary. To solve this problem, you need to modify the VSHOST32.EXE process. Run the EDITBIN utility on the VSHOST32.EXE...

We received our Sage Accpac 5.6 disks last week. There are a lot of little changes and some fairly big ones. Here is a sampling of what’s new:

Completely new installation process. There is now an integrated install. No more installing each module separately. Yeah! Integrated activation. The activation process is now integrated so that you pick the modules you want activated from a list and then let it do it’s thing. This keeps you from having to baby sit the process when you are doing a lot of modules. Reporting and operational tweaks in G/L, A/R and A/P Reworked Bank Rec process in Bank Services. A lot of other changes to Bank Services. A new business intelligence reporting module. and the big change is a completely rewritten serialized and lot tracking module that is integrated in to I/C, O/E, P/O and P/M. Plus you don’t purchase the modules separately now. Serialized and Lot Tracking are sold as one add on module. There are a lot of other changes but that’s the main list. DB2 is no longer supported and full PDF manuals have disappeared. The help files are the main source for operational information now.

...

Last year after we installed Vista on our development machines, we came across a problem with .Net programs and Accpac.

We’ve been writing some of our custom Accpac programs in .Net and calling the Accpac COM API to interface with Accpac ERP. But when these .Net programs were run on our Vista machines they would crash. But only when using one of the Accpac COM API’s that would pop open a window. Calling a Finder through the API or doing a ShowErrors call would instantly crash the program. Everytime.

After doing a LOT OF investigating, we discovered that the problem was related to DEP (Data Execution Protection). If we disabled DEP on our workstations, the problem would go away.

With some more digging, we came up with a theory that fits pretty well. Turns out the ATL library had some problems with DEP (up to and including V7.1). They do some kind of runtime code creation for thunking that makes DEP think the program is trying to run data. And then DEP causes the program to crash. Guess who uses ATL components in their COM API? Correct! Accpac! Everytime we used the COM API that opened a window of some kind, an ATL component was called and BAM! Down it goes.

...

We had a problem last week regarding a custom Accpac view we were developing. It was a straight flat file view with no business logic. We cobbled it together basically to get the table created in the database with the appropriate data dictionary entries. We’ll never call it except for the initial ViewCreate call.

The problem was that it would load fine on our development workstations but not on the customers server. After scratching our heads a bit, we ran DEPENDS on the DLL to see if there were any missing dependencies. Sure enough, it was reporting that it couldn’t find the Visual C runtime (V8). Since Accpac uses the same runtime, we couldn’t understand what was going on.

Turns out that the default build in the Accpac SDK uses the –manifest switch. This embeds a Windows manifest file in the resources of the DLL. The manifest specifies the build of the MSVC runtime and sets it to the newest version on the build machine. Since we had a newer version than what was loaded on the customers machine,...