Develop Reference

C# console app using Interop.domino.dll - failing when running as Scheduled Task

I have written a C# console application that uses the Interop.domino.dll assembly to interact with domino / notes to create, update and delete documents. The application runs successfully when running it manually through a cmd prompt or through Visual Studio. However, when we try to set the application up as a scheduled task (running under a domain service account) it fails with the following error:
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following
error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
The error occurs as soon as we try to use an object from the Interop.domino.dll, specifically when try to create an instance of the NotesSession object as per the following:
ISession notesSession = new NotesSession();
After some investigation I found that the interop assembly requires a desktop to interact with and that if we ran the scheduled task with the service account logged into the machine that the scheduled was running on the scheduled task would run successfully. While logged in as the service account you could see that the application would bring up a svchost.exe window while the application was running and that is the reason it requires the desktop.
However, having the service account logged into the machine all the time is not an acceptable solution as it means that the account has to be logged in again each time the server restarts. There are also some security concerns around having about allowing a service account to login to machines.
So, I was wondering if anyone had any suggestions on how to get around this issue? Is there a way to suppress any UI that the assembly tries to show? Alternatively, can anyone suggest an alternate to a scheduled task which would achieve a similar result. What we need to do is:
Have the application run at a set interval (IE - once a day / once an hour)
Ideally, have it run under a domain service account (as opposed to a local system account)
Run without requiring the service account to be logged into the machine / UI elements from the Interop.domino.dll suppressed
We have thought about writing a similar application making use of the notes web services rather than the Interop assmebly and will go down that path if we can't get the console app running as a scheduled task. However, we would like to make use of what I have already written if possible.
Update 01/05/12
I have tried etting the NOTESNTSERVICE OS environment variable as per #dna-man solution. However, this did not solve the issue.
For now we have set the application up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account, but the application does work so we will go with this approach for now.
There was an answer that suggested this approach, but it seems to have been removed so I can't mark it as correct. I might leave the question open a bit to see if anyone else has any suggestions.

If your code is running on a Domino server you must make sure the OS environment variable NOTESNTSERVICE=1 is set. You can find out more abou this environment variable in the Lotus C API documentation, but it applies to the COM API as well when running as a service. I had created way back in 2003 a VB.NET application that had to run as a service, and setting this environment variable was the key. If it wasn't set, the service would stop working as soon as I logged off the machine. To make sure somebody didn't forget to set this environment variable when installing the service in the future I simply had my service manager start code set this environment variable directly on startup using the VB.NET call to SetEnvironmentVariable. It had to be set before creation of the Domino session object.

It's hard to say exactly why, but I believe it's failing to read the registry information for the Lotus interop classes. Obviously the entries are there, otherwise it would not work while running manually. So let's consider other possibilities.
I don't even know if this is possible, but os your application running as 32 bit when run manually, but 64 bit when scheduled? IBM doesn't support the Domino COM classes on Win64, and I'm pretty sure that the first symptom of that is that the registry l
A more mundane possibility is that the service account just doesn't have access to read the registry entries for the Notes/Domino install on the machine, possibly because the software was installed under a specific user account.

I ended up modifying the application slightly to set it up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account. However, this approach does allow the application to run without requiring an account to always be logged in and does allow for the interop UI elements to be shown (thus avoiding the error).
To schedule the windows service to perform the task at a set interval (which I set at once a day) I used the Timer solution proposed here.

ClickOnce deployed application asks to install update even if there exists none

I have ClickOnce deployed application coded in C#. I wonder if anyone experienced the same problem.
Clickonce deployed application checks for updates always before execution. One of my clients using this application informs me about an update which the application asks to install even if there exists no update we had deployed. My clients installed the update. But what was installed is the same version. At this point, I wonder why a clickonce application decides if there is an update deployed. I believe this is a weird problem that I could not figure out why it happened.
Is there anyone who knows why such a weird thing could happen ? I suspect may be some of files of the installation removed, thus leading a reinstallation of the program. But I am not sure.

We've had this problem before with some of our clients. The problem ended up being due to object caching on their proxy server. Basically, the client actually is running an old version, so when they start your program, ClickOnce correctly reports that there is an update available. The problem is that the client's proxy server caches an old copy of your program, so when the updater runs the proxy server intercepts the update request and instead sends back a cached copy of your program in place of the update. ClickOnce doesn't notice until its next startup that the "updated" program still isn't actually updated.
The solution is to get in touch with your client's IT staff and try to figure out where the caching is happening and have them clear the cache. It's probably on their custom-built proxy server, but webfilters like Barracuda do object caching too, and so do some of the fancier Cisco routers.

C# ClickOnce deployment for Windows Services?

What are some best practices for being able to deploy a Windows service that will have to be updated?
I have a Windows service that I will be deploying but might require some debugging and new versions during the beta process. What is the best way to handle that? Ideally, I'd like to find a ClickOnce-style deployment solution for Windows services but my understanding is that this does not exist. What is the closest I can get to ClickOnce for a Windows service?

A simple solution that I use is to merely stop the service and x-copy the files from my bin folder into the service folder.
A batch file to stop the service then copy the files should be easy to throw together.
Net stop myService
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre
net start myService

I have a system we use at work here that seems to function pretty well with services. Our deployed system has around 20-30 services at any given time. At work we use a product called TopShelf you can find it here http://topshelf-project.com/
Basically TopShelf handles a lot of the service related stuff. Installing, Uninstalling etc all from the cmd line of the service. One of the very useful features is the ability to run as console for debugging. You build one service, and with a different cmd line start you can run it as a console to see the output of the service. We added one custom feature to this software that lets us configure profiles in advance. Basically our profiles configure a few things like logging, resource locations etc so that we can control all that without having to republish any code. All we do is run a command like
D:\Services\ServiceName.exe Core.Profiles.Debug or
D:\Services\ServiceName.exe Core.Profiles.Production
to get different logging configurations.
Our build script creates install.cmd and uninstall.cmd scripts for each of our services all we do is copy the files to the server and run the script. If we want to see debug output we stop the service and double click the exe and we get a console to read all the output.
One more thing that topshelf has which we don't use because its not necessary is the concept of shelving (there is documentation on this website for this). This allows you to update the service without having to "restart" but you still need to copy the files manually unless you build an automated system for that.
However, my suggestion if you need 100% service availability is to have a redundant system. No matter how you configure your service for updates you cannot avoid hardware failure causing downtime without an automated failover system. If said system was in place my recommended update strategy would be to turn off 1 node, update, test, turn on turn off the other node, update, test and turn the 2nd node back on. You can do this all of course with a simple script. This may be a more complicated system than you need but if you can't take a service offline for a simple restart that takes 5 seconds then you really need some system in place to deal with hardware issues because I can guarantee it will happen eventually.

Since a service is long-running anyway, using ClickOnce style deployment might not be viable - because ClickOnce only updates when you launch the app. A service will typically only be launched when the machine is rebooted.
If you need automatic update of a service then your best bet might be to hand-code something into the service, but I'd forsee problems with almost any solution: most install processes will require some level of user interaction (if only to get around UAC), so I can't imagine this would lead an answer that doesn't involve getting a logged-on user in front of the screen at some point.
One idea that might just work is active-directory deployment (or some similar equivalent). If your service is deployed via a standard MSI-type installer, AD allows you to update the application silently as part of the computer policy. I suspect you'd have to force the server to refresh the AD policy (by rebooting or using gpupdate from the console), but other than that it should be a hands-off deployment.

I would suggest using the "plugin" approach on this, that is, using the Proxy Design Pattern.
While using this pattern, an independant thread may verify over a folder for updates. You will need to use ShadowCopy over your assembly deployment. When your service update-thread encounters a new version of your service, it shall unload the current production assembly and load the new version, without stopping the service itself. Even more! Your service should never notice the difference, if there is no breaking code within your assembly.

I would suggest to create a normal setup project, and add the windows service project output in that setup project.
For more information please refer to http://support.microsoft.com/kb/816169.

CD Burning within an XBAP

I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks

I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.

Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.

C# application is freezing on vista/7, not on xp/2003 server

I wrote a C# application that is running well on my xp development machine.
When my client is running it on different PC, it seems to freeze on both vista and 7 machines.
I would like to know if there is any issue on running dotnet applications on vista/7.
I compiled the application for both framework 2.0 and 3.5 but it didn't help.
The log file neither doesn't help.
Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ?
Thank you in advance for any help.
Pierre.

Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).
For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.
To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.
Check this link for more information: Making apps UAC aware.
As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).

You do not give much information in order for us to help a great deal.
I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.

Ask your client to capture a process dump using Windows Task Manager,
In Task Manager, find the process that hangs.
Right click and capture a memory dump.
Then you can do some analysis on the dump to see why it hangs.
If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com

csharp applications are supposed to run on vista/win7. This is their home:)
Your problem is not the OS. its your application.
Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.
Check for project independencies and make sure you have shipped to your clients everything your project needs.
and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.