Leaderboard

@jugador Looking at some of the links that you've provided, it appears that you've already done some research into side-by-side (sxs) assemblies. So I'll provide the following information based on that assumption, meaning my explanations will remain at a relatively high level and not delve into the details unless requested. Getting sxs working in AutoIt is not that difficult once you understand the steps that need to be done and why. If you have additional questions, which I'm sure you will, please don't hesitate to ask. The attached zip file contains all of the files and scripts that I will discuss in my example, except for the script that actually creates the manifest and ChilkatAx-9.5.0-x64.dll (which is too big to attach). I will provide details as to what my manifest tool does. As requested, I have provided an example using Chilkat. Here is a description of what's in the zip file: Chilkat_Manifest_9.5.0_All_Classes.xml: The <file> section from the full dll manifest. Chilkat_Manifest_9.5.0_Free_Classes.xml: The <file> section of the dll manifest that contains only free objects. Chilkat_SxS_Test.au3: The sxs example script. Chilkat_SxS_Test.exe: A compiled version of the The sxs example script. Chilkat_SxS_Test.exe.manifest: The sxs manifest needed by the compiled example. ChilkatAx-9.5.0-x64.dll: I had to remove this file from the zip because it was too big to attach. Please make sure it is in the script dir or PATH. ChilkatAx-9.5.0-x64.dll.manifest: The full Chilkat dll manifest. (only needed to get <file> section) test.json: A small test JSON file used by the example script. Making sure that you have unregistered any existing Chilkat dll, run "Chilkat_SxS_Test.exe". If successful, you should see the following output in notepad (tested on Win7 x64): Chilkat version = 9.5.0.76 { "store": { "book": [ { "category": "reference", "author": "Nigel Rees", "title": "Sayings of the Century", "price": 8.95 }, { "category": "fiction", "author": "Evelyn Waugh", "title": "Sword of Honour", "price": 12.99 } ], "bicycle": { "color": "red", "price": 19.95 } } } store.book[0] = { "category": "reference", "author": "Nigel Rees", "title": "Sayings of the Century", "price": 8.95 } store.book[0] Size = 4 As you can see in the test script (au3), the output is generated using properties and methods of "Chilkat_9_5_0.JsonObject" in the unregistered Chilkat Dll (that should be in the script dir or PATH) Let's drill down a little further. If you look at the script (au3), the real "magic" of creating the sxs manifest and removing the exe's internal manifest happens in an #AutoIt3Wrapper_Run_After directive. Of course this can be done in a standalone step, but I do it as a part of the compile. The output of that directive pretty much describes the process: 2023-12-11 07:45:22 Cmd Line Parms: -exe "C:\Users\<redacted>\Documents\ZZZ\Chilkat Side-by-Side Test\Chilkat_SxS_Test.exe" -include "C:\Projects\Personal\AutoIt\SxS_RegisterFree_COM_Manifest_Tool\Chilkat_Manifest_9.5.0_Free_Classes.xml" 2023-12-11 07:45:22 2023-12-11 07:45:22 2023-12-11 07:45:22 Script Started - SxS_RegisterFree_COM_Manifest_Tool v3.3.14.5 64-bit 2023-12-11 07:45:22 2023-12-11 07:45:22 Get manifest using API 2023-12-11 07:45:22 > Manifest successfully retrieved 2023-12-11 07:45:22 2023-12-11 07:45:22 Add "include" file to manifest 2023-12-11 07:45:22 > "C:\Projects\Personal\AutoIt\SxS_RegisterFree_COM_Manifest_Tool\Chilkat_Manifest_9.5.0_Free_Classes.xml" file added to manifest 2023-12-11 07:45:22 2023-12-11 07:45:22 Write external manifest 2023-12-11 07:45:22 > External manifest successfully written 2023-12-11 07:45:22 2023-12-11 07:45:22 Remove internal manifest 2023-12-11 07:45:22 > Internal manifest successfully removed 2023-12-11 07:45:22 2023-12-11 07:45:22 Script Ended - Execution time: 0.005 Secs - Exit Code: 0 2023-12-11 07:45:22 Basically, when I compile the script the manifest tool gets the compiled exe's internal manifest, reads the specified xml manifest file and adds its information to the exe's manifest, writes it out the updated manifest using the appropriate file name, and deletes the exe's internal manifest. My manifest tool is an AutoIt script that uses _WinApi functions from the WinAPIRes.au3 UDF library, it does not use any external utilities. However, I used Angus Johnson's ResourceHacker tool extensively in my development and testing. Because it has a command line interface, I had considered using it instead of the _WinAPI functions but I ultimately decided against it in an effort to make it totally independent of external utilities (and being the techie I am, I preferred to do it using code). Now, let's look at the manifest files. "ChilkatAx-9.5.0-x64.dll.manifest" is the Chilkat dll's full manifest provided by Chilkat. "Chilkat_9.5.0_Free_Classes.xml" is the the portion of that file that is used to modify the exe's manifest. It contains, from the <file> element of the full manifest, just a list of the free Chilkat objects. I could have used the full <file> element but I chose to use a subset to show that it isn't necessary. You only need the objects that will be used by the script. If you look at "Chilkat_SxS_Test.exe.manifest" you will see the exe's previous internal manifest that now includes the <file> element from the "Chilkat_9.5.0_Free_Classes.xml" file. That's pretty much it. It may be a lot to absorb at first, but it is pretty simple once you understand the information that needs to be pulled from the dll's manifest and added to the compiled exe's sxs manifest. There are a few little "gotchas" that you may run into, like having to touch the exe file's "modified date" if you make changes to the manifest without recompiling in order for the exe to pick up the changes. But the whole process is pretty straight forward. I'll give you a chance to absorb all of that information. As I said, I'm sure you'll have questions, especially about my "SxS_RegisterFree_COM_Manifest_Tool" and how it works with the exe's resource information, retrieves the manifest from it, and the removes it. As I mentioned, I just chose to write my own tool to create the manifest. It is much easier to use ResourceHacker, especially its command line interface. However, if you want to know more about the _WinApi functions I used to to manipulate the exe's resource information, feel free to do so. Since I stopped working on a reply after the other person's post, I cobbled all of this back together rather quickly. Hopefully, I didn't leave anything out, make any misstatements, or mistakes. I hope this helps. Additional links that may be useful: https://learn.microsoft.com/en-us/windows/win32/sbscs/guidelines-for-creating-side-by-side-assemblies https://learn.microsoft.com/en-us/windows/win32/sbscs/about-side-by-side-assemblies- Other associated topics listed on their pages. CHILKAT_SXS_EXAMPLE.ZIP

Try not to dig too deeply, you will suffer from information overload. To understand what's needed in the external sxs manifest, using the example that I provided, I would start by first looking at the manifest provided by Chilkat for his Dll's. Because I compiled a 64-bit exe, that means look at "ChilkatAx-9.5.0-x64.dll.manifest". The only part of that file that you need to be concerned with is the part between <file> and </file>, inclusively. That is the part that needs to be added to the compiled exe's internal manifest in order to create the external sxs manifest. The contents of "Chilkat_Manifest_9.5.0_Free_Classes.xml" is the part of the full manifest that I added to the exe's original manifest. It only contains entries for the Chilkat objects that don't require a Chilkat license. I didn't need to strip it down to just those objects. I could've used the complete list of objects. So the combination of the original manifest and "Chilkat_Manifest_9.5.0_Free_Classes.xml" is what makes up the exe's external manifest ("Chilkat_SxS_Test.exe.manifest"). The only other important part of the whole process, was removing the exe's internal manifest from its resources so that it will look for the external manifest. What I just described is basically what my SxS_RegisterFree_COM_Manifest_Tool automates.

I don't think I completely understand your question. I think you are asking what's needed in the exe's manifest if it is not a .Net dll. My discussion and example of sxs manifests is only in relation to dll's with COM/ActiveX interfaces, not .Net dll assemblies. As for what's needed in the example exe's manifest, just look at the "Chilkat_SxS_Test.exe.manifest" file. All that was needed from the Chilkat dll's manifest was the <file> section of the manifest's xml file. And more specifically, the only objects needed from the <file> section are those used in the compiled exe. Of course you can include all of the objects, but the only ones needed are the ones you used in the script. So all that is needed in a compiled AutoIt exe's manifest is the exe's original manifest information and the <file> element that defines the COM objects that will be used in the compiled exe and the associated <typelib> element. To be clear, the only part of the manifest below that was added to the exe's original manifest is the <file>...</file> element, which is defining the Chilkat COM objects used in the compiled exe. Minimum Chilkat_SxS_Test.exe.manifest (the example script only uses Chilkat's Chilkat_9_5_0.JsonObject object): <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <file name="chilkatax-9.5.0-x64.dll"> <typelib tlbid="{004cb902-f437-4d01-bd85-9e18836da5c2}" version="1.0" helpdir="" resourceid="0" flags="HASDISKIMAGE" /> <comClass clsid="{82df90a6-29b8-4bfc-9433-76a7bc3e0e82}" threadingModel="Apartment" tlbid="{004cb902-f437-4d01-bd85-9e18836da5c2}" progid="Chilkat_9_5_0.JsonObject" description="ChilkatJsonObject Class 9.5.0" /> </file> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df"/> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> </application> </compatibility> </assembly> I hope that answers your question. If not, can you reword it or add more context so I can fully understand what you're asking? Update: For the record, I'm not familiar with the mt.exe tool that you referenced. It was not one of the tools that I used when learning about how to implement sxs manifests in order to use COM Dll's, without registration in AutoIt.

It may have been a typo, and this is what is being referred to Whether my guess is right or wrong, I can logically and definitively say to tommytx123 that if you don't try it, it won't work..

So your reference to the Chilkat library and my UDF confused me. I apologize for the confusion I caused.