Deployment issue

Waldo2k2

I'm having an issue deploying the sdk dll's with our product.

When our program is run from a development machine (which happens to have the full sdk installed) everything works flawlessly.

If we run the program on a machine where only the required red-gate dll's are deployed, something goes wrong.

The licensing seems to work (no prompt or error). However, it seems to skip past synchronizing the schema (I do see a few messages returned about what objects need to be built, but they never actually get built). It skips over the data comparison entirely (most likely because the objects were never built during schema sync).

I'm really at a loss here, here is a list of the files that are being deployed with our application (they reside in the same folder as our dlls, they are not registered in the GAC).
RedGate.Shared.SQL.dll
RedGate.Shared.Utils.dll
RedGate.SQLCompare.ASTParser.dll
RedGate.SQLCompare.Engine.dll
RedGate.SQLCompare.Rewriter.dll
RedGate.SQLDataCompare.Engine.dll

So to recap, it seems to connect to both databases, begin comparing the schema, then just stop for no reason. We receive no error messages at all. None of the database objects are actually built.
This only occurs on deployed installations, it does not happen on the machine that was used to develop the program, which has the Comparison SDK installed.

Brian Donahue

Hi,

On the surface the issue doesn't make a lot of sense.. if the licensing is to blame, the code would throw an exception right at the database registration and never get to the comparison stage.

You may want to open your compiled .NET assembly using reflector and look for the licence in the "resources" section. If the licensing had been done correctly, there would be an <assembly name>.licenses resource inside it and you should see your SQL SDK serial number in there.

If you don't see it, then double-check that you have got a licenses.licx file linked to your Visual Studio project and rebuild it. If you're using an automated build tool instead of building directly in VS please let me know because there may be some extra tasks to add to your automated build to get the licensing to work.

Renaming the assembly will also break the licensing.

Waldo2k2

I can verify that the serial is present in my dll (I can see it in notepad even). So I'm not sure it's a licensing issue.

Waldo2k2

What's even stranger is that after throwing in some logging to a file, I can see that it in fact did build differences.
It seems to have a message in the Work object for each database object that needed to be created.

So it seems like it's making it all the way to my call to ExecuteBlock...and then failing silently? The whole thing is wrapped in a try catch and it's not raising any exceptions. I can't figure out why this is failing on these machines. They are attempting to sync between the same two databases as the machine that does work...anyone have any bright ideas?

Waldo2k2

Well I found what was causing the problem, the good news is that it doesn't have anything to do with the toolkit.

The bad news is that I still don't quite understand why the problem was so erratic.

I have a .net user control that executes the synchronization on another thread so that a progress bar and status message can remain updated. This object is COM accessible and is used inside our application (written in PowerBuilder). The class exposes several events, one of which I called SqlCompiled. All this event does is return the SQL of the executionblock before it is executed...however it seems that this was causing the thread to abort prematurely...I'm not sure if it was because of the size of the string being returned, or just a race-condition, but commenting out the code that raises that event fixes the problem. Go figure.

So I guess the lesson is to log your sql to a file, rather than trying to pass it around all over the place in memory ;-)

Thanks for the help, it did help me to stop looking at licensing and deployment as causes of the problem and dig in a little deeper.

Brian Donahue

Thanks for the update. I don't see any obvious reason for this happening, but it may be caused by the script generation -- maybe just returning the ExecutionBlock in your AsyncResult and converting it to a SQL script on the main thread would work?

Waldo2k2

Once we finish the mad dash to get this out the door I will try putting it in the asyncresult and see what happens. For now I'm just going to log it to a file.

The more I think about it, this is probably just an issue caused by COM, or more precisely, how PowerBuilder deals with COM (this wouldn't be the first time it's caused me trouble). It may still cause other issues raising the event from the main thread.

Thanks again.