Patch Upgrades

[vbaker]

What is the correct way to upgrade a version (e.g., 3.3.0.1) using a binary patch, say 3.3.0.11)?

If I run the .exe for the patch "on top of" the existing 3.3.0.1 version, I find that both the old binaries for 3.3.0.1 as well as the new 3.3.0.11 binaries are present.

The 3.3.0.1 dlls are still in:
C:\Program Files\Syncfusion\Essential Studio\Assemblies\1.1\

But the patched dlls are in:
C:\Program Files\Microsoft Visual Studio .Net 2003\Common7\IDE\PublicAssemblies\

Projects have to have their References sections manually re-defined in order to get the new, patched binaries linked in.

Please let me know if there is a better way.

Thanks,
Van Baker

[Daniel Jebaraj]

Hi Van,

Patches are installed side-by-side with the existing version. However, only the latest version is installed to the Public Assemblies Folder (for all installed versions of Visual Studio.NET).

All projects that do not have copy local set to true for the assemblies should automatically pick up the new assemblies. Is this not happening?

Thanks,
Daniel

>What is the correct way to upgrade a version (e.g., 3.3.0.1) using a binary patch, say 3.3.0.11)?
>
>If I run the .exe for the patch "on top of" the existing 3.3.0.1 version, I find that both the old binaries for 3.3.0.1 as well as the new 3.3.0.11 binaries are present.
>
>The 3.3.0.1 dlls are still in:
> C:\Program Files\Syncfusion\Essential Studio\Assemblies\1.1\
>
>But the patched dlls are in:
> C:\Program Files\Microsoft Visual Studio .Net 2003\Common7\IDE\PublicAssemblies\
>
>Projects have to have their References sections manually re-defined in order to get the new, patched binaries linked in.
>
>Please let me know if there is a better way.
>
>Thanks,
>Van Baker
>

[Sue Harris]

Hi Daniel,

It''s certainly not working quite right for me. My projects have Copy Local set false, and whenever I installed a patch I had to copy the 1.1 assemblies folder from the patch precompiled assemblies directory to the C:\Program Files\Syncfusion\Essential Studio\Assemblies directory for the patch assemblies to be used in my project.

On the other hand it was obviously doing *something* since when I uninstalled the patch (and replaced that 1.1 directory with the old precompiled assemblies directory) I kept getting errors trying to compile which basically indicated that something was still finding the patch assemblies (The error was usally something along the lines of Syncfusion.Grid dll 3.301.0.0 is referencing newer assembly Syncfusion.Core dll 3.301.0.20). I eventually uninstalled the Syncfusion Suite completely and deleted all the registry keys and file folders to solve the problem. Interestingly enough this problem (http://www.syncfusion.com/Support/Forums/message.aspx?MessageID=34255) cropped up again after I uninstalled the patch.

Regards,
Sue

[Daniel Jebaraj]

Hi Sue,

Thanks for the details. The problem was related to the following.

* We no longer use the old Assemblies folder. The new assembly manager (in the patches and 4.x) installs directly to the VS.NET assembly folders. The problem is that there could potentially be a conflict with different assemblies in these locations. We have changed this now such that the new assembly manager copies over to the old assemblies folder if one exists.

* Even if both locations are updated, in some projects the hint path can cause problems. In such cases it is best to remove and readd references.

With reference to the assembly manager build issue you still have to delete the key. This has been fixed with 4.x.

Best regards,
Daniel

>Hi Daniel,
>
>It''s certainly not working quite right for me. My projects have Copy Local set false, and whenever I installed a patch I had to copy the 1.1 assemblies folder from the patch precompiled assemblies directory to the C:\Program Files\Syncfusion\Essential Studio\Assemblies directory for the patch assemblies to be used in my project.
>
>On the other hand it was obviously doing *something* since when I uninstalled the patch (and replaced that 1.1 directory with the old precompiled assemblies directory) I kept getting errors trying to compile which basically indicated that something was still finding the patch assemblies (The error was usally something along the lines of Syncfusion.Grid dll 3.301.0.0 is referencing newer assembly Syncfusion.Core dll 3.301.0.20). I eventually uninstalled the Syncfusion Suite completely and deleted all the registry keys and file folders to solve the problem. Interestingly enough this problem (http://www.syncfusion.com/Support/Forums/message.aspx?MessageID=34255) cropped up again after I uninstalled the patch.
>
>Regards,
>Sue

[Colt0219 Attractive]

when it happens, it’s like hearing a familiar song for the first time again — something you instantly understand, yet can’t fully explain. That’s the magic this game captures.

[Acha Zx085]

Hi Van, what you’re seeing is normal for how that binary patch works. The patch doesn’t replace the existing 3.3.0.1 assemblies in place; instead, it installs the updated 3.3.0.11 binaries side-by-side in Visual Studio’s PublicAssemblies folder. Because both versions coexist, Visual Studio won’t automatically switch existing project references to the newer DLLs, which is why you have to update the References manually. Unfortunately, there isn’t a more seamless upgrade mechanism with this patching approach. The usual recommendation is to either manually retarget the references once, or uninstall the older version before applying the patch if you want to avoid confusion from having multiple versions installed—similar to how having the correct PS2 BIOS 4mb in place avoids conflicts when running different builds.