Hello Wolfang,
ok, so i´ll do.
Here is my manifest for rprt309.dll.
The name ist important. Is has to be "rpRT309.Manifest". This file has to be in the same directory as rprt309.dll itself. There is also the option to "burn" it into the dll with the MT.EXE from C:Program Files (x86)Windows Kits10bin10.0.18362.0x86.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity name="RPRT309" version="3.9.0.0" type="win32" processorArchitecture="x86"/>
<file name="rpRT309.DLL">
<comClass
clsid="{7610B471-BE49-11D0-877E-00609726A5CE}"
description="ReportPro Runtime"
tlbid="{7610B470-BE49-11D0-877E-00609726A5CE}"
threadingModel="Apartment"
miscStatusContent="cantlinkinside,insideout,activatewhenvisible,renderingisdeviceindependent,invisibleatruntime"
progid="ReportPro.Runtime.39">
<progid>ReportPro.Runtime</progid>
</comClass>
</file>
<file name="rpRT309.tlb">
<typelib
tlbid="{7610B470-BE49-11D0-877E-00609726A5CE}"
version="3.9"
helpdir=""
flags="hasdiskimage"/>
</file>
</assembly>
So here´s the manifest for the application. It´s names Application.exe.Manifest and has to be in the same directory as the application itself or could be "burned in" with the MT-Tool or could be inserted into the application with a define like this:
resource CREATEPROCESS_MANIFEST_RESOURCE_ID RC_RT_MANIFEST c:ApplicationprojectspathApplication.exe.manifest
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="20.0.7.1"
processorArchitecture="X86"
name="application.exe"
type="win32"
/>
<description>This.is.an.application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="RPRT309"
version="3.9.0.0"
processorArchitecture="x86" />
</dependentAssembly>
</dependency>
</assembly>
And of course there could be other dependencies in this manifest, like c# assemblies to extend the abilities of VO.
Enjoy.
Heiko J. Pongratz
Reportpro 3 and windows 10
Reportpro 3 and windows 10
Thank you very much, Heiko!
Wolfgang
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Reportpro 3 and windows 10
Hello to all ...
For some months I have a problem using My Applicaton (VO 2.8 )and calling the RP3-Runtime with Win 10. The error message is "Variable not initialized". This problem is something that has changed with an Update in Win 10, because prio my Application wiorked fine with Win 10.
If I Inspect the local Object I see, that some objects are Null. I think the Init-Routine "InitAutoObject()" does not work anymore.
Any Suggestion what I can do?
I Tried to register the DLL rpRT309 - but there is an errorMessge from RGSRV33.
I tried to buid a minfest-File like mentioned by HeikoP - no result.
For some months I have a problem using My Applicaton (VO 2.8 )and calling the RP3-Runtime with Win 10. The error message is "Variable not initialized". This problem is something that has changed with an Update in Win 10, because prio my Application wiorked fine with Win 10.
If I Inspect the local Object I see, that some objects are Null. I think the Init-Routine "InitAutoObject()" does not work anymore.
Any Suggestion what I can do?
I Tried to register the DLL rpRT309 - but there is an errorMessge from RGSRV33.
I tried to buid a minfest-File like mentioned by HeikoP - no result.
Reportpro 3 and windows 10
Hello Unknown,
i think if manual registration of rprt309.dll fails, reportpro-runtime can´t work.
It´s important to run regsvr32 rprt309.dll with local administration rights and it´s important that it throws no error! If you don´t have enough rights it fails.
We had certain incidents where a former registration of rprt309.dll disapeared on a computer and hte user had to re-register. We haven´t found out, why and how this happened, therefore we use this sidebyside registration now, which works really good. I would recommend to check first, that your programm runs with a manual registrated rprt309.dll. If this works, you can try the sidebyside thing.
Greetings from Germany
Heiko
i think if manual registration of rprt309.dll fails, reportpro-runtime can´t work.
It´s important to run regsvr32 rprt309.dll with local administration rights and it´s important that it throws no error! If you don´t have enough rights it fails.
We had certain incidents where a former registration of rprt309.dll disapeared on a computer and hte user had to re-register. We haven´t found out, why and how this happened, therefore we use this sidebyside registration now, which works really good. I would recommend to check first, that your programm runs with a manual registrated rprt309.dll. If this works, you can try the sidebyside thing.
Greetings from Germany
Heiko
Reportpro 3 and windows 10
Hi Horst,
I would recommend to use SideBySide whenever possible.
Unfortunately the ReportPro people have not changed the GUID of the DLL, so you will get trouble if you have more that one version of the ReportPro DLL on your machine as you can always have registered only one of them.
SxS (the short name for SideBySide) removes these restrictions as there is no registration needed - it is done in the moment of the application start, and the best thing is that you can even load such COM dlls from network drives.
But SxS has its own problems: it is not very well documented, and errors most of the time show only up in the eventlog.
If you need to check SxS errors, you could use a cmd file with this content:
Simply start this cmd file when you start your executable and stop it when the error has beed occurred.
Wolfgang
P.S. in the bottom of this page you can find some informations: https://docs.xsharp.it/doku.php?id=com_module_sample
I would recommend to use SideBySide whenever possible.
Unfortunately the ReportPro people have not changed the GUID of the DLL, so you will get trouble if you have more that one version of the ReportPro DLL on your machine as you can always have registered only one of them.
SxS (the short name for SideBySide) removes these restrictions as there is no registration needed - it is done in the moment of the application start, and the best thing is that you can even load such COM dlls from network drives.
But SxS has its own problems: it is not very well documented, and errors most of the time show only up in the eventlog.
If you need to check SxS errors, you could use a cmd file with this content:
Code: Select all
sxstrace Trace -logfile:systrace.out
sxstrace Parse -logfile:systrace.out -outfile:sxstrace.txt
notepad sxstrace.txt
Wolfgang
P.S. in the bottom of this page you can find some informations: https://docs.xsharp.it/doku.php?id=com_module_sample
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Reportpro 3 and windows 10
Hi Horst,
sorry, I forgot something important: if you change the manifest of your application, you have to rebuild your application completely to force the inclusion of the new/changed manifest. So a "Touch" or "Rebuild All" could be needed.
And then use a manifest viewer to see if your manifest changes have been written to the exe.
Wolfgang
P.S. this is sometimes one of the most frustrating steps when integrating COM libraries into a VO application - and I have many of them.
sorry, I forgot something important: if you change the manifest of your application, you have to rebuild your application completely to force the inclusion of the new/changed manifest. So a "Touch" or "Rebuild All" could be needed.
And then use a manifest viewer to see if your manifest changes have been written to the exe.
Wolfgang
P.S. this is sometimes one of the most frustrating steps when integrating COM libraries into a VO application - and I have many of them.
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Reportpro 3 and windows 10
Hi
First Thanks to all for your suggestions.
I tried some of them (Rebuidl all) but no changing.
Now i'm working on the migration of my Application from VO 2.8 to XSHARP, hoping to solve the Problem there. Until now I try to do it with XIDE, but on long time I will port it to Visual Studio.
I think this will take a few days.
When I have problems to do this is it better to post my problems here or is there another forum ?
First Thanks to all for your suggestions.
I tried some of them (Rebuidl all) but no changing.
Now i'm working on the migration of my Application from VO 2.8 to XSHARP, hoping to solve the Problem there. Until now I try to do it with XIDE, but on long time I will port it to Visual Studio.
I think this will take a few days.
When I have problems to do this is it better to post my problems here or is there another forum ?
Reportpro 3 and windows 10
Hello Unknown,
i think it´s always a good idea to migrate you vo programm to x#. But i thinks that doesn´t solve your problem with vo-application, reportpro-runtime and windows 10 at all. You have to register rprt309.dll to use it or you use sidebyside. If registrating fails, then there is something else broken. And this behaviour is unusual.
My advise:
Try to solve this first. After then migrate!
I have another idea, what could be the reason: Do you habe a standard printer installed? If not please select a printer as standard. If you don´t have on, reportpro reports fail!
Greetings from Germany
Heiko
i think it´s always a good idea to migrate you vo programm to x#. But i thinks that doesn´t solve your problem with vo-application, reportpro-runtime and windows 10 at all. You have to register rprt309.dll to use it or you use sidebyside. If registrating fails, then there is something else broken. And this behaviour is unusual.
My advise:
Try to solve this first. After then migrate!
I have another idea, what could be the reason: Do you habe a standard printer installed? If not please select a printer as standard. If you don´t have on, reportpro reports fail!
Greetings from Germany
Heiko
Reportpro 3 and windows 10
Hello Wolfgang,
I have spent hours getting SideBySide (one of the many bad Microsoft ideas) working throughout the years and often, on a new system or with an updated DLL my long list of problems and their solutions grows as often I encountered a new problem. The last one was that mt.exe wasn't anymore in the location where it was and VS didn't care to give a clear message that it wasn't there. The for last error I eventually resolved by exporting the (original) manifest.mef, deleted it, imported it again, touched the aef where it was in (which revealed some extra missing .ico files which I copied), and then it finally compiled and created a starting exe.
Dick
I would advice to stay away from SideBySide as much as possible unless you have to, because you won't be able to register your DLL's manually everywhere your software is supposed to run.wriedmann wrote:Hi Horst,
I would recommend to use SideBySide whenever possible.
I have spent hours getting SideBySide (one of the many bad Microsoft ideas) working throughout the years and often, on a new system or with an updated DLL my long list of problems and their solutions grows as often I encountered a new problem. The last one was that mt.exe wasn't anymore in the location where it was and VS didn't care to give a clear message that it wasn't there. The for last error I eventually resolved by exporting the (original) manifest.mef, deleted it, imported it again, touched the aef where it was in (which revealed some extra missing .ico files which I copied), and then it finally compiled and created a starting exe.
Dick
Reportpro 3 and windows 10
Hi Dick,
yes, you are right, sometimes it takes a few hours to make things work because they are not documented very well, and the error messages are not clear.
But after all, when distributing your software, it saves much more time than you have spent.
With SxS I can run my software from a network drive without any installation. And that alone helps a lot.
Wolfgang
yes, you are right, sometimes it takes a few hours to make things work because they are not documented very well, and the error messages are not clear.
But after all, when distributing your software, it saves much more time than you have spent.
With SxS I can run my software from a network drive without any installation. And that alone helps a lot.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it