Manifest file reference to embedded DLL?

[pdvos]

Hello,

Hope I have the terminology right I'm not very well versed in programming.

I am working on a small tool that sends email via easendmail.dll (COM) and blat.dll and it works without COM registration using a manifest file that replaces the standard autoit manifest.

If I have easendmail.dll next to the compiled exe it works.

My next step was to put everything in one exe file, so I used the "File to Base64 String Code Generator" tool to convert both blat.dll and easendmail.dll and embed them in the tool.

Then I used DLLFromMemory from the subrogation script to run? blat.dll and easendmail.dll but only the blat.dll part works.

The manifest has the following content:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 	<dependency>
 		<dependentAssembly>
 			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df"/>
 		</dependentAssembly>
 	</dependency>
  <file name="easendmail.dll" hashalg="SHA1">
    <comClass clsid="{DF8A4FE2-221A-4504-987A-3FD4720DB929}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="Mail Class"></comClass>
    <comClass clsid="{FF80631D-E750-4C67-AFC3-5170AB72518B}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="FastSender Class"></comClass>
    <comClass clsid="{EAFC4EAA-9390-492A-8E53-E179527780F6}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="Certificate Class"></comClass>
    <comClass clsid="{036C2F8C-8D3C-4F4B-9B36-3B6F1D29C0B4}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="CertificateCollection Class"></comClass>
    <comClass clsid="{DD6B3C53-1871-4ADF-9C71-24B682012371}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="SimpleJsonParser Class"></comClass>
    <comClass clsid="{6C589C71-6FDC-4859-A9CD-F3A7EA2206D0}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="SimpleJsonArray Class"></comClass>
    <comClass clsid="{60534020-0887-486D-B6B7-0F177D43C00C}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="OAuthResponseParser Class"></comClass>
    <comClass clsid="{539C9DBC-57D4-4ACB-8A91-329A2CC6270E}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="BrowserUi Class"></comClass>
    <comClass clsid="{7CFF2534-946A-495E-A356-7D01F71F3449}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" description="HttpListener Class"></comClass>
    <typelib tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" version="1.0" helpdir="" flags="HASDISKIMAGE"></typelib>
  </file>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
 		<security>
 			<requestedPrivileges>
 				<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
 			</requestedPrivileges>
 		</security>
  </trustInfo>
  <comInterfaceExternalProxyStub name="IMail" iid="{1AD28FC9-0C71-4E89-85C9-CAECDE8BE3AB}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="ICertificate" iid="{A2809780-C98E-4C6D-A552-DAB146D4AD12}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="ICertificateCollection" iid="{DC8D5635-B8E7-441E-B550-CE1BF3BA5C55}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="IFastSender" iid="{92298BE3-ADEC-438F-800C-CF6311A7DF1D}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="ISimpleJsonArray" iid="{B62298B7-A091-4A42-8D50-B7F0194DE25A}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="ISimpleJsonParser" iid="{08088DBB-A031-4DCE-A4DF-7683CBE706AF}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="IBrowserUi" iid="{217785E8-1188-4FDD-BBB8-1EB104D32151}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="IHttpListener" iid="{011E1175-8AC1-40D5-BC61-903999FAAC8D}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="_IMailEvents" iid="{68CB8B02-D4AA-4A16-97A0-6B9488F98189}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020420-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="_IFastSenderEvents" iid="{A1B45F08-67E7-4276-A7CA-7664C08F9EF7}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020420-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="IOAuthResponseParser" iid="{2B8C75E2-9631-4834-9D3B-32C51C7FB962}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  <comInterfaceExternalProxyStub name="_IHttpListenerEvents" iid="{A386C7CB-8547-451E-A7DC-CD74BA675247}" tlbid="{8B5A2BD0-5638-4CCA-A7FF-91B9E6768AC4}" proxyStubClsid32="{00020420-0000-0000-C000-000000000046}"></comInterfaceExternalProxyStub>
  	<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>

As you can see it points to easendmail.dll and here everything comes to a hold.

I tried to adjust the manifest file to use filename="mytool.exe" 🙈 but that didn't work.

Is there a way to use the COM bits directly from the easendmail.dll without a manifest like blat.dll

My current solution is to write the base64 content to the easendmail.dll at startup. But I hoped for a nicer solution

 

So my question would be is this possible?  Or am I mixing up my dll's and it's foolish to try.

 

 

 

 

[TheXman]

7 hours ago, pdvos said:

I am working on a small tool that sends email via easendmail.dll (COM) and blat.dll

I assume (or hope) that you meant "...sends email via easendmail OR blat.dll".    Why?  What is the purpose of having 2 different SMTP utilities in one tool.  Is there functionality in one that the other doesn't have?  It just seems like unnecessary bloat.

Let's take a step back.  What is the primary goal that you are trying to accomplish with this tool?  Is it just to be able to send mail from a script?  If so, there are numerous ways to do it and some don't even require using 3rd-party CLI utilities or DLLs.  Or is this just an exercise in trying to learn how to execute code from memory?  If that's the case, again, why start with 2 different DLL's that use different implementations (COM vs API)?

 

7 hours ago, pdvos said:

I tried to adjust the manifest file to use filename="mytool.exe" 🙈 but that didn't work.

You seem to be lacking an understanding of what the <file> tag is defining in the original manifest and why you can't just change the name from the COM's dll file to your exe.  Needless to say, that modification to the manifest makes no sense.  In general, the discussion of application manifest internals is beyond the scope of AutoIt.  If working with manifests are a necessity, then it might benefit you to take some time to study and understand them more before trying to make modifications to them and playing with them from within AutoIt scripts.

 

7 hours ago, pdvos said:

Is there a way to use the COM bits directly from the easendmail.dll without a manifest like blat.dll?

Sure, that's what COM registration (regsvr32) is for.  if you successfully register the eaSendMail DLL prior to execution, then you do not need to mess with the manifest in your script. 

I am familiar with blat, the command line utility, but not blat.dll.  But from what you've said, it sounds like blat.dll exposes/exports APIs that can be called within the DLL using DllCall functions in AutoIt.  eaSendMail exposes COM object methods that are called from within AutoIt.  Those are 2 completely different ways of implementing/extending functionality using DLLs.

7 hours ago, pdvos said:

So my question would be is this possible?  Or am I mixing up my dll's and it's foolish to try.

In general, what's possible is usually only limited by your imagination and skill.

 

Edited July 14, 2020 by TheXman

[pdvos]

Quote

assume (or hope) that you meant "...sends email via easendmail OR blat.dll".    Why?  What is the purpose of having 2 different SMTP utilities in one tool.  Is there functionality in one that the other doesn't have?  It just seems like unnecessary bloat.

Let's take a step back.  What is the primary goal that you are trying to accomplish with this tool?  Is it just to be able to send mail from a script?  If so, there are numerous ways to do it and some don't even require using 3rd-party CLI utilities or DLLs.  Or is this just an exercise in trying to learn how to execute code from memory?  If that's the case, again, why start with 2 different DLL's that use different implementations (COM vs API)?

Actually I have 4 ways in that script CDO,Powershell, Blat.dll and easendmail (oh and also a pushover fallback)

I'm an administrator and some processes need monitoring and some are pretty critical. However CDO has issues and is kinda deprecated, it works for the most time but the moment you change region settings it stops working (and MS won't fix it)

So I figured out I could use powershell to send email .. but the part that sends emails got deprecated too it works for now but why not have a backup for that too.

I played with blat.dll and that  works and is pretty resilient but it only support plain smtp without encryption so I found out about easendmail.

Quote

You seem to be lacking an understanding of what the <file> tag is defining in the original manifest and why you can't just change the name from the COM's dll file to your exe.  Needless to say, that modification to the manifest makes no sense.  In general, the discussion of application manifest internals is beyond the scope of AutoIt.  If working with manifests are a necessity, then it might benefit you to take some time to study and understand them more before trying to make modifications to them and playing with them from within AutoIt scripts.

Yes I am fully aware that I lack a lot when it comes to programming, it's all fun and games till one of our devs looked at my code and his eyes started to bleed.

I really hope to squeeze in more time to figure it out but for now I hoped for a manifest bypass trick but you have made it clear there isn't one .. so thanks for that.

 

Quote

Sure, that's what COM registration (regsvr32) is for.  if you successfully register the eaSendMail DLL prior to execution, then you do not need to mess with the manifest in your script. 

I am familiar with blat, the command line utility, but not blat.dll.  But from what you've said, it sounds like blat.dll exposes/exports APIs that can be called within the DLL using DllCall functions in AutoIt.  eaSendMail exposes COM object methods that are called from within AutoIt.  Those are 2 completely different ways of implementing/extending functionality using DLLs.

I didn't want to register the dll because it might mess with existing applications that also work with easendmail or a different version. (dll hell)

You are correct I tried to find a COM less one but seems that in dev world COM is hot and happening.

Quote

In general, what's possible is usually only limited by your imagination and skill.

 

In Dutch we say "Breek me de bek niet open" and time I might add. 

For now I solved it to extract the dll from the tool if needed ....

Thank you for taking time to reply.

 

 

 

 

 

 

[TheXman]

Since using 3rd-party apps are not prohibited in your environment, have you looked at using CMail or SwithMail?  I prefer cmail and have a UDF that wraps its functionality into a single function call.  I have used CMail for several years without any issues and still use it in my scripts to this day.  It can handle just about anything including STARTTLS/SMTPS,  inline embedded attachments, priorities, delivery status notifications, and much more.  Both are command line utility but can be easily run from scripts.  Also, both are very reliable, highly functional, and easy to use.

If your environment doesn't have an issue with 3rd party services, then you could look at using a service like SendGrid.  If you don't foresee sending more than 100 emails a day, then it's free.  It offers both a SMTP Relay and an API for sending email.  I have used it in the past also.  It is built for high-volume mass marketing campaigns but works just as well for the occasional email alert.  It is a VERY feature-rich and reliable service and it has been around for a very long time.

I'm not sure what kind of region setting is causing you so much grief but since SMTP is a standard that has been around for what seems like forever, I'm sure that whatever region issue you are encountering can be overcome.

You should be able to find a single solution that meets your need or maybe have a single fail-over/backup solution.  Having 4 or 5 solutions, that all do the same thing, seems a bit excessive -- but what do I know, right. 

12 hours ago, pdvos said:

In Dutch we say "Breek me de bek niet open" and time I might add. 

Yes, you're right about time being a limiting factor.  I forgot about that one.  Being retired, time isn't usually something I think about much anymore.  But time is a very important factor that can limit what's possible. 

Edited July 16, 2020 by TheXman

[Skysnake]

@pdvos welcome

Have you looked at @water's Outlook UDF? You can that UDf to create emails and send using the local Outlook client (if present, obviously).

 

 

[pdvos]

Thank you for the welcome

But installing outlook on every server would be a license nightmare.