Does anybody know why the Catel Framework examples run so slowly when launched from Visual Stuio? When running any of the demo apps, load time is extremely slow (around 45 seconds). However, running the .exe directly, outside of VS is as fast as one would expect (< 2 sec).
System: Windows 7 Pro x64, Visual Studio 2012 Pro
Edit
I narrowed down the problem by reducing the App.xaml.cs code to this:
protected override void OnStartup(StartupEventArgs e)
{
var serviceLocator = IoC.ServiceLocator.Default;
}
..and set a breakpoint at the opening brace of the method, after F5 it takes 40 seconds to hit that breakpoint. If I comment-out that servicelocator line and then run, the breakpoint is hit almost instantly.
Edit 2
..ok, to narrow it down further: any reference to Catel.Core will cause the huge delay. When I have the Catel reference line uncommented, the following extra lines are seen in the Output window:
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'c:\users\bruce.tw\documents\visual studio 2012\Projects\CatelLoggingTinker\CatelLoggingTinker\bin\Debug\Catel.Core.dll', Symbols loaded.
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Accessibility\v4.0_4.0.0.0__b03f5f7f11d50a3a\Accessibility.dll'
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Security\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Security.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
The thread '<No Name>' (0x3d24) has exited with code 0 (0x0).
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_64\System.Transactions\v4.0_4.0.0.0__b77a5c561934e089\System.Transactions.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Data.SqlXml\v4.0_4.0.0.0__b77a5c561934e089\System.Data.SqlXml.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\UIAutomationProvider\v4.0_4.0.0.0__31bf3856ad364e35\UIAutomationProvider.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'CatelLoggingTinker.vshost.exe' (Managed (v4.0.30319)): Loaded 'Anonymously Hosted DynamicMethods Assembly'
If my only line in OnStartup is
Catel.Collections.ListDictionary<int, int> cc = new Catel.Collections.ListDictionary<int, int>();
... then the output window first shows that Catel.Core.dll is loaded right away, but then UIAutomationProvider.dll takes ages to appear.
Is there something wrong with my GAC?
I also struggled with this Problem (in fact on many Computers i tried it out!).
My solution was the following:
in VS "Debug-> Options and Settings":
Debugging -> Symbols:
choose Option "All modules, unless excluded".
Add the following to the exclude list:
Catel.Core.dll
Catel.Extensions.Controls.dll
Catel.MVVM.dll
(and whichever Catel module you happen to reference).
The strangest thing: after i did this once, i can remove those dll from the exclude list, and still start Debugging fast :-/
(although this might Change after next reboot....idk)
But i Keep them in exclude list anyways, cause i don't Need to load those Modules at all - they should be "bugfree" afterall, at least shouldnt be in need to debug by me....
Regards
Johannes Colmsee
Update: it turns out you can easily disable loading of all Catel dll's by only specifying "Catel.*.dll" in the excluded module list
Another nice side-effect by this is, that you wont be bothered by those "Manifest Resouce stream not found exceptions" or the "ThreadAbortException" (when PleaseWaitService finishes) (all for Debug Settings "Break on Thrown Exceptions")
A few hints:
Performance considerations
Check if the debug logger is taking too much time (the output window is trying to keep up, slowing things down)
Check if you have symbols enabled, then it might be visual studio trying to load source symbols (see docs)
Related
I'm trying to set a breakpoint on CLSIDFromProgID while debugging Excel (32 bit) as I'm looking into an add-in issue. So far I haven't figured out how to do it on Win10. Both the Visual Studio (17) debugger and WinDbg say they have loaded the symbols for ole32.dll. I've tried:
in WinDbg:
ole32!CLSIDFromProgID
ole32!_CLSIDFromProgID
ole32!_CLSIDFromProgID#8
CLSIDFromProgID
_CLSIDFromProgID
_CLSIDFromProgID#8
in visual studio:
{,,ole32.dll}CLSIDFromProgID
{,,ole32.dll}_CLSIDFromProgID
{,,ole32.dll}_CLSIDFromProgID#8
CLSIDFromProgID
_CLSIDFromProgID
_CLSIDFromProgID#8
In some cases it seemed to set a breakpoint but it was actually in some other module so that didn't help. If I view the exported CLSIDFromProgID in ole32.dll on Win10 I see:
CLSIDFromProgID (forwarded to api-ms-win-core-com-l1-1-0.CLSIDFromProgID)
When I use the DBH tool included with WinDbg to list the symbols in ole32.pdb, the only CLSIDFromProgID symbol I see is:
_imp__CLSIDFromProgID
while debugging Excel and having already executed the code which calls CLSIDFromProgID I don't see module api-ms-win-core-com-l1-1-0.dll loaded.
Anyone successful putting a breakpoint of any of these forwarded API's?
[Edit]
By the way, if you want Excel to call CLSIDFromProgID you can enter the following in a cell:
=RTD("MyBogus.ProgId", "", "Foo")
Thanks,
Nick
I have the following projects in a Visual Studio 2012 solution:
Native (no /clr) static lib project, compiled with /ZI for Edit And Continue.
C++/CLI DLL project, which references the above static lib.
The C++/CLI project builds with the following warning:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
If /OPT:NOLBR is added to the linker options of the C++/CLI project, the warning becomes:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
Any attempt to change the incremental linkage setting of the C++/CLI project doesn't change the warning (C++/CLI projects never link incrementally anyway).
I understand that I won't be able to use Edit And Continue in the C++/CLI project, because this is not supported. Indeed, changing /ZI to /Zi (disabling Edit And Continue) in the static lib project eliminates the warning, but I can't do that - other non-CLR consumers of that lib need to use Edit And Continue.
How can I get rid of this warning without disabling Edit And Continue in the static lib (and hopefully without maintaining separate build configuration for native and CLR users of the static lib)? I mean, is there any way to ask the linker to ignore the /EDITANDCONTINUE directive that is embedded in the referenced static lib (much in the same way that /NODEFAULTLIB can ignore /DEFAULTLIB directives)?
I have created a minimal VS solution that reproduces the described issue.
due to '/OPT:LBR' specification
This is a nonsense error message, that linker option is only effective for ARM binaries. This is simply a bug, using /OPT:NOLBR takes the sting out of it and you get the real warning.
Which is accurate enough, although it doesn't win any prizes either, you asked for Edit+Continue support in your static lib project but that is not available for a mixed-mode .NET assembly. The undocumented /IGNORE linker option is available to suppress warning messages but this one is ranked as an "unignorable warning" by Chapell.
You'll have to live with this warning as long as you don't want to change your static lib project. It is completely benign. You won't get it when you recompile it with /Zi.
There is no other way than to
disable "Edit And Continue" in the library
create a separate build configuration for "Edit And Continue (/ZI)" and "Program Database (/Zi)"
Of course: I am not aware that there is a predefined macro to determine between /ZI and /Zi... so you need to define your own preprocessor directive to distinguish between these configurations...
I had the same problem and found the only solution is to delete the .vcxproj and .sln files of the project and create the project again.
But then in an old copy of the same project I found a better solution: I changed in the projectname.vcxproj file the line
Profile true
to
Profile false
and LNK4075 warnings disappeared.
It had been the Visual Studio Profiler who had caused the troubles.
A few days back I had help from SO members in creating a safe plugins system, using interfaces to communicate between the main app and the dll's. This solved some problems I was having with Access Violations and memory leaks, and all is working perfectly now, without errors or crashes.
So, I've been creating some long due plugins for this project, which lead me to another problem: Speed
What I'm doing right now is, when the main app starts, loads all dll's in a specific folder that follow a determined name patern.
The code I'm using to load them is the following:
if FindFirst(cfg.ExePath+cPathPlugins+'\np*.npl', faAnyFile, SR)<>0
then Exit; // npl files are in fact renamed dll's
PluginHost := TPluginHost.Create as IPluginHost;
Plugins := TObjectList<TPluginInfo>.Create(True);
repeat
if (SR.Attr <> faDirectory)
then begin
dll := LoadLibrary(PChar(cfg.ExePath+cPathPlugins+SR.Name));
if dll<>0
then begin
#PluginInit := GetProcAddress(dll, 'PluginInitialize');
if Assigned(PluginInit)
then begin
Plugin := TPluginInfo.Create;
try
Plugin.Dll := dll;
Plugin.Intf := PluginInit(PluginHost);
Plugins.Add(Plugin);
except
Plugin.Free;
end;
end
else FreeLibrary(dll);
end;
end;
until FindNext(SR)<>0;
System.SysUtils.FindClose(SR);
This bit of code takes about 45s to load 7 plugins. None of these dll's have initialization code, and the PluginInitialize just passes the host interface and retrieves the plugin interface.
My questions are:
Can the number of methods on the interfaces affect the loading speed at this point? I don't believe so, but would like to confirm.
Could this loading time be cut somehow, while still loading them at startup?
I did thought of an alternative, having the names of the plugins to load in the database and loading the dll itself only upon first usage, but I'd prefer not to apply this, as some of these plugins must run automatically upon completion of some events during the app's execution, and not only though a menu option on demand.
I thought maybe this could be done loading the plugins in background, on a different thread, but I don't know if this could bring any risks, since I've never used threads.
I believe the main risk with using threads is when one tries to access variables that are being modified by the other, is this right?
In this case, that wouldn't happen, I think, as what comes after the plugin loading is grabing the plugins name (using one of its methods) and adding it to a TButtonGroup, that is created before starting the search for the dll's.
Do you believe this would be a good solution?
If not, any alternative you can point me to?
Your problem is that the DLL's are large. You need to create the DLL's using run time packages. That way, the code is only loaded once. Each DLL will include duplicates of the same code. LoadLibrary will load the DLL and call the initialization code for each DLL. This means that package X would be linked into each plugin that uses it and would be initialized when each plug in is loaded. (corrected)
For standalone EXE file, taking off runtime packages is great. It makes deployment much simpler. When you want to start using a plugin system, it's best to switch to a system that includes runtime packages.
That doesn't mean that you need to keep every runtime package separate. For example, if you only use Dev Express controls in the main application or in a single plugin then you can let Delphi compile that package into the App/DLL.
To change which runtime packages you wish to keep separate and which ones you wish to include in the project go to the "Packages-Runtime Packages" page in the project options. There is a check box that lets you choose to link with runtime packages. Underneath is a text box. In this text box you can specify the names of the packages that you want to keep separate.
dllmain.cpp(16): warning C4447: 'main' signature found without threading mode
l. Consider using 'int main(Platform::Array<Platform::String^>^ args)'.
Above is a warning I got from building a Windows Store App DLL project. I didn't change anything in that default dllmain.cpp file except for including my own version of pch.
The documentation for this warning (along with many VS2012 errors/warnings) is nowhere to be found on MSDN and here is the only relevant link I can find:
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/6daa9587-fe54-4e84-a8b9-0e5c52c2f6e8/
and the op there didn't get an answer.
If anyone knows what it means and how to fix it, it would be great!
As far as I can tell, you can safely ignore the warning. The compiler cribs when it sees a Win32-style DllMain being compiled using the /ZW flag (Consume Windows Runtime Extensions). However, the function gets called as you'd normally expect.
Alternatively, you can work around the warning by compiling dllmain.cpp without /ZW. You might need to adjust the PCH settings for this to properly work. This is the path taken by the DLL (Windows Store apps) C++/CX project template in Visual Studio.
Incidentally, the reason you do not get the warning when you're trying to build a Windows Runtime Component project (which builds everything using /ZW) is that a Windows Runtime Component doesn't declare a DllMain. This is not to say that it can't; it just picks up the dummy DllMain that the CRT defines (which basically turns off per-thread initialization and reports success).
I'm having a weird problem when trying to register the .dll i created using regsvr32.
During development everything went fine, the debug version registers and works fine. Now i wanted to create a Release version, but that Version does not register anymore.
regsvr32 comes up with the following error:
The module "mpegsplitter.dll" failed to load.
Make sure the binary is stored at the specified path or
debug it to check for problems with the binary or
dependent .DLL files.
The specified procedure could not be found.
Some research brought me to the dependency walker, which does tell me this
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
It also does show a dependency on "crtdll.dll" that the debug version does not have (The function view shows soem functions that normally should be in ole32.dll), which is colored red'ish.
So far so good, i guess its somehow related to what the dependency walker shows there.
But where do i go from here? How do i fix it?
Any help would be greatly appreciated, that has been keeping me busy for several hours already.
Thanks!
I have the same problem. When I compared the different between "Command Line" (in Project Properties -> Linker) of Release and Debug mode, I found out that the "Optimization" options (in Project Properties -> Linker) of Release mode was turned on while ion Debug not.
Turning of Optimization for linker in Release mode solved the problem
Is it possible that the debug version is compiled with _ATL_MIN_CRT but the release version isn't? You can set this with the Minimize CRT Use in ATL project property as well.
I fixed it. It was actually being caused by the order of some mingw libraries i included to link against ffmpeg. Oh well, how weird.
In my case, the difference was in Module Definition File entry between DEBUG and RELEASE. The DEBUG version was pointing to the .DEF file where as the RELEASE had it empty.