Is it possible to load your WPF application when the machine starts up? Our WPF application is taking 30 seconds on our existing client hardware, and we'd like to "hide" that by having our application startup when the machine is booted. But the fact that our application boots on startup should be invisible to the user.
How would we go about building such a thing? Is there a term to google that will provide a tutorial? It would be nice if there's a WPF specific-one we can grab.
Note: In case there's any moral qualms to this (since I agree that having 20 programs startup when your computer does is frustrating!), we're building software for a specialized industry who will be using their computer to run primarily our applications.
The easiest approach would be
make sure your big libraries are installed in the GAC
write a dummy app that uses (most of) those libs. Actually use them so they get loaded.
run the dummy on startup
make the dummy stop by itself, or keep it alive hidden
This would in no way interfere with the starting of the normal application. The benefit is that the libraries get loaded and jitted. The drawback that your app still needs to load & initialize.
Sasha had a few more tips not listed here, rebasing your modules, leveraging the prefetch facility and compression (UPX, yuk!).
Related
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
WPF launches certain method which calls external exe and waits , and then accesses a file which was an output of external exe. Assuming I would build this application with a consideration of porting to Silverlight 4 later what should I do ?
In order to do this you would need to go through Silverlight's COM automation. I'm sure there's some out-of-process COM server that you could use to start a process. But at that point you've already
limited your application to Windows
require full trust
will only work in "out of browser" mode
At that point, you really gotta ask whether or not it makes any sense to port to Silverlight. WPF is particularly suitable for the above scenarios. You can use ClickOnce to achieve a similar (actually, superior) client update experience and you won't have to jump through hoops to do something as simple as spawning an external process.
I've become familiar with the new concept of "out of browser" web applications, supported in the recent Silverlight, JavaFX, Adobe AIR etc.
Listening recently to a podcast on the subject by Scott Hanselman, I've become aware that one of the purposes behind these new architectures is to allow for "desktop-application-feel". Also, I understand some (or all) of these allow for some offline access to a sandbox of resources. This really sounds as if these frameworks could be an alternative to "real" desktop applications, as long as the application does not require messing with the user's machine (i.e. access to peripherals, certain file IO, etc).
I have a very specific question. My application needs to run at start-up. Is it possible to do so using such a framework without requiring the user to download and run a certain executable?
For example, I could always direct the user to download a small EXE that will put a .lnk file in the start-up directory, but I want to avoid such a patch.
To summarize: is it possible to have an out-of-browser web application setup itself to run at start-up without requiring file download?
To further clarify, this question does not come from an "evil" place, but rather from trying to decide whether "out-of-browser" frameworks are indeed a proper alternative to a desktop application, for my specific requirements.
The BkMark example here shows how to start an application on startup using Adobe Air. So, yes it is possible.
So, here's the deal: web apps in general will have a security context around them, and by default won't have access to write to the filesystem (outside of a temp files), access the registry, etc.
One way is, as you said, have the user run something or configure it so the lnk is executed on startup.
Another way, and I think, more in line of what you want, is that the user can run the program himself, click some button in the application, and it's configured.
I know with Java you could do this, but the user has to allow full access to their system, because your app would need to change System configuration. Then you could just configure it (by writing a lnk to your WebStart JNLP in the Startup folder)
For Internet Exploder, Javascript apps do have write access to the disk.
For other (better-secured) browsers you will either need to have a download, or Adobe AIR.
Assuming you are building for Windows, launching an executable at startup can be done several ways.
For user session startup, you can achieve this either by putting a lnk file in the appropriate folder, or with a registry entry. For operating system startup, you can achieve this with a registry entry. There are several permutations:
run application once on boot (UI not allowed)
run application every boot (UI not allowed)
start service every boot according to policy set in registry
run application once on user session start
run application every user session
Since an out of browser application has UI I expect you mean run application every user session and in this case you may as well put an LNK file in the user's startup folder.
I just created a shortcut for an SL4 OOB application, and this was the Target of the shortcut:
"C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" 2635882436.localhost
A search of my disk revealed that location 2635882436.localhost is a folder.
C:\Users\<mylogin>\AppData\LocalLow\Microsoft\Silverlight\OutOfBrowser\2635882436.localhost
I rather doubt an OOB app of any type could place a shortcut in the Startup folder unless you somehow obtained Full Trust.
I am kind of lost here, and I don't know what to do
I have a problem that I don't know what the source of it.
We have a large wpf application, that is built similar to prism (composite application)
Actually we are using lots of prism library.
I wrote a module to replace an existing module.
And the application now is loading my module, instead of the old module.
I start to notice, with the new module, that sometimes the application freeze for 20-30 seconds without any response, and then it work smoothly after that.
The freeze is not consistent, and there is no pattern or a specific reason that cause it.
I am suspecting that could be my module that is causing that freeze.
But at the same time, many other developers introduced new code to the application.
My question is there a way to trace that freeze?
Is there a way to compare the old module and the new module that I wrote?
I can run the application with my module, and trace the application, and then I can change the config file to load the old module.
Is there a way to compare between the two?
Should I do profiling?
and if profiling will help, then what should I look for?
any other tool could help?
Thanks a lot for any reply
It sounds like you are doing a long running operation on your UI thread. Are you making any database / webservice calls from the main thread? I think one of the easiest things to do is run it in the debugger, and when it freezes, hit the "pause" button. Visual Studio will pause execution at the current location, and you can examine what is taking so long.
If the problem isn't immediately obvious there, I would definitely start profiling the application to track this down.
I noticed that WPF application startup is sometimes pretty slow. Does anybody know if the the cause is the elements initialization or DLLs loading or something else?
The text below was extracted from this MSDN article on Improving WPF applications startup time (Edit: now merged into WPF Application Startup Time)
Application Startup Time
The amount of time that is required for a WPF application to start can vary greatly. This topic describes various techniques for reducing the perceived and actual startup time for a Windows Presentation Foundation (WPF) application.
Understanding Cold Startup and WarmStartup
Cold startup occurs when your application starts for the first time after a system reboot, or when you start your application, close it, and then start it again after a long period of time. When an application starts, if the required pages (code, static data, registry, etc) are not present in the Windows memory manager's standby list, page faults occur. Disk access is required to bring the pages into memory.
Warm startup occurs when most of the pages for the main common language runtime (CLR) components are already loaded in memory, which saves expensive disk access time. That is why a managed application starts faster when it runs a second time.
Implement a Splash Screen
In cases where there is a significant, unavoidable delay between starting an application and displaying the first UI, optimize the perceived startup time by using a splash screen. This approach displays an image almost immediately after the user starts the application. When the application is ready to display its first UI, the splash screen fades. Starting in the .NET Framework 3.5 SP1, you can use the SplashScreen class to implement a splash screen. For more information, see How to: Add a Splash Screen to a WPF Application.
You can also implement your own splash screen by using native Win32 graphics. Display your implementation before the Run method is called.
Analyze the Startup Code
Determine the reason for a slow cold startup. Disk I/O may be responsible, but this is not always the case. In general, you should minimize the use of external resources, such as network, Web services, or disk.
Before you test, verify that no other running applications or services use managed code or WPF code.
Start your WPF application immediately after a reboot, and determine how long it takes to display. If all subsequent launches of your application (warm startup) are much faster, your cold startup issue is most likely caused by I/O.
If your application's cold startup issue is not related to I/O, it is likely that your application performs some lengthy initialization or computation, waits for some event to complete, or requires a lot of JIT compilation at startup. The following sections describe some of these situations in more detail.
Optimize Module Loading
Use tools such as Process Explorer (Procexp.exe) and Tlist.exe to determine which modules your application loads. The command Tlist <pid> shows all the modules that are loaded by a process.
For example, if you are not connecting to the Web and you see that System.Web.dll is loaded, then there is a module in your application that references this assembly. Check to make sure that the reference is necessary.
If your application has multiple modules, merge them into a single module. This approach requires less CLR assembly-loading overhead. Fewer assemblies also mean that the CLR maintains less state.
Defer Initialization Operations
Consider postponing initialization code until after the main application window is rendered.
Be aware that initialization may be performed inside a class constructor, and if the initialization code references other classes, it can cause a cascading effect in which many class constructors are executed.
Avoid Application Configuration
Consider avoiding application configuration. For example, if an application has simple configuration requirements and has strict startup time goals, registry entries or a simple INI file may be a faster startup alternative.
Utilize the GAC
If an assembly is not installed in the Global Assembly Cache (GAC), there are delays caused by hash verification of strong-named assemblies and by Ngen image validation if a native image for that assembly is available on the computer. Strong-name verification is skipped for all assemblies installed in the GAC. For more information, see Gacutil.exe (Global Assembly Cache Tool).
Use Ngen.exe
Consider using the Native Image Generator (Ngen.exe) on your application. Using Ngen.exe means trading CPU consumption for more disk access because the native image generated by Ngen.exe is likely to be larger than the MSIL image.
To improve the warm startup time, you should always use Ngen.exe on your application, because this avoids the CPU cost of JIT compilation of the application code.
In some cold startup scenarios, using Ngen.exe can also be helpful. This is because the JIT compiler (mscorjit.dll) does not have to be loaded.
Having both Ngen and JIT modules can have the worst effect. This is because mscorjit.dll must be loaded, and when the JIT compiler works on your code, many pages in the Ngen images must be accessed when the JIT compiler reads the assemblies' metadata.
Ngen and ClickOnce
The way you plan to deploy your application can also make a difference in load time. ClickOnce application deployment does not support Ngen. If you decide to use Ngen.exe for your application, you will have to use another deployment mechanism, such as Windows Installer.
For more information, see Ngen.exe (Native Image Generator).
Rebasing and DLL Address Collisions
If you use Ngen.exe, be aware that rebasing can occur when the native images are loaded in memory. If a DLL is not loaded at its preferred base address because that address range is already allocated, the Windows loader will load it at another address, which can be a time-consuming operation.
You can use the Virtual Address Dump (Vadump.exe) tool to check if there are modules in which all the pages are private. If this is the case, the module may have been rebased to a different address. Therefore, its pages cannot be shared.
For more information about how to set the base address, see Ngen.exe (Native Image Generator).
Optimize Authenticode
Authenticode verification adds to the startup time. Authenticode-signed assemblies have to be verified with the certification authority (CA). This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. It also makes sure that there is a full chain of valid certificates on the path to a trusted root. This can translate to several seconds of delay while the assembly is being loaded.
Consider installing the CA certificate on the client computer, or avoid using Authenticode when it is possible. If you know that your application does not need the publisher evidence, you do not have to pay the cost of signature verification.
Starting in .NET Framework 3.5, there is a configuration option that allows the Authenticode verification to be bypassed. To do this, add the following setting to the app.exe.config file:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Compare Performance on Windows Vista
The memory manager in Windows Vista has a technology called SuperFetch. SuperFetch analyzes memory usage patterns over time to determine the optimal memory content for a specific user. It works continuously to maintain that content at all times.
This approach differs from the pre-fetch technique used in Windows XP, which preloads data into memory without analyzing usage patterns. Over time, if the user uses your WPF application frequently on Windows Vista, the cold startup time of your application may improve.
Use AppDomains Efficiently
If possible, load assemblies into a domain-neutral code area to make sure that the native image, if one exists, is used in all AppDomains created in the application.
For the best performance, enforce efficient cross-domain communication by reducing cross-domain calls. When possible, use calls without arguments or with primitive type arguments.
Use the NeutralResourcesLanguage Attribute
Use the NeutralResourcesLanguageAttribute to specify the neutral culture for the ResourceManager. This approach avoids unsuccessful assembly lookups.
Use the BinaryFormatter Class for Serialization
If you must use serialization, use the BinaryFormatter class instead of the XmlSerializer class. The BinaryFormatter class is implemented in the Base Class Library (BCL) in the mscorlib.dll assembly. The XmlSerializer is implemented in the System.Xml.dll assembly, which might be an additional DLL to load.
If you must use the XmlSerializer class, you can achieve better performance if you pre-generate the serialization assembly.
Configure ClickOnce to Check for Updates After Startup
If your application uses ClickOnce, avoid network access on startup by configuring ClickOnce to check the deployment site for updates after the application starts.
If you use the XAML browser application (XBAP) model, keep in mind that ClickOnce checks the deployment site for updates even if the XBAP is already in the ClickOnce cache. For more information, see ClickOnce Security and Deployment.
Configure the PresentationFontCache Service to Start Automatically
The first WPF application to run after a reboot is the PresentationFontCache service. The service caches the system fonts, improves font access, and improves overall performance. There is an overhead in starting the service, and in some controlled environments, consider configuring the service to start automatically when the system reboots.
Set Data Binding Programmatically
Instead of using XAML to set the DataContext declaratively for the main window, consider setting it programmatically in the OnActivated method.
The most useful advice on fixing WPF startup performance I've ever seen was given in this other question: run "ngen update" in every framework folder.
It seems that Microsoft can't keep their ngen cache up-to-date, which results in your application pretty much recompiling half the .NET framework every single startup.
Hard to believe, but seems to be true.
The startup time of a WPF Application can be much faster if you use Framework 3.51 and not 3.5 or 3.0. The 3.51 is really an improvement.
This is an old thread, but I've ended up here several times while trying to fix a startup performance issue with WPF apps on my Win10 system, so I thought I'd state an answer which may help others - an answer that takes a horrible 5 second startup time for all WPF apps on this system down to just a few milliseconds. Remove the nVidia "3d Vision" driver. I have a GeForce GTX 650 card, and the "3d Vision" driver doesn't seem to offer anything useful, so removing it is no problem for me. The VisualStudio2015 performance analysis tool finally helped show that almost all the 5 second startup time was spent IDLE after a call through nvapi64.dll - the nVidia driver. Wow.
What helped me the most from the excellent article that Stuart links to was the XmlSerializer trick. That really shaved up quite a few seconds. Furthermore don't underestimate defragmenting your HD :-)