I've got a new problem right here:
I've written a small WPF-Application which monitors my TAPI-Lines. On Incoming Calls or Outgoing Calls the program does some Database-Actions. This works really fine so far.
What i want to do now, is a Win-Service which does all of these Actions. Several Employee are login in and out onto the Server where the WPF-App is running. When the User-Session stops, the WPF-App stops too. This is why i've written a Windows Service.
After installing (installutil) and starting the Service from services.msc it seems that the Service is running fine but it isnt. New Incoming/Outgoing Calls doesnt were not written to the Database.
So i asked myself if there are any limitations for those services? Im am using EntityFramework for the Database-Actions and a Telephone-API for monitoring the calls.
While debugging this service everything works just fine... but in "live-mode" nothing works...
Can Anybody give me some tips??
THX
It propably is a permissions issue.
The service runs per default as user "SYSTEM". In the properties tab of the service you can change this to a user that has the appropriate permissions.
Related
so I'm using a custom protocol handler for RDP from two sources, both are working great to connect.
Testing to the same remote machine clipboard works for one, but not the other.
Since I've tested on multiple source machines and same remote machine, using the same credentials, it does not seem to be an auth or machine issue, but an issue with the information that is being fed into the protocol handler or something to that affect.
The only difference is the auto generated file (which deletes itself on session connection).
I've seemingly scoured the internet and mostly found gpo/registry/rdpclip.exe fixes, none of which aim to solve this problem.
My questions:
How can I view detailed session information (such as the options that are passed using an rdp file) of active sessions? query user, query session, qwinsta etc do not have that capability it seems. For example: I see redirectclipboard:i:value in microsoft docs, how can I find what is currently set for this option, in a current session?
Are there any other suggestions on what may be causing this problem?
I have a code that is used in an Winforms application. The same code is also used in a Windows Service (exe running as Windows Service). The code grabs the handles to ICONs. But what I found is that, in Task Mangaer (and GDI View), when I ran the Winforms Application the app shows the GDI count. But when I ran the code via Windows Service, the service instance in Task Manager isn't showing any count for GDI. So, does this mean that Windows Service can never hold a GDI handle? If so, how does the code work, that is how is the code that runs on the handle actually working in Windows Service.
Services are in fact able to create and use GDI handles in exactly the same way as an ordinary application, except that the display surfaces are not visible to the user.
However, Task Manager is only able to query this information for processes that are in the same session that it is running in, and services always run in a separate session.
So, basically, just a false alarm. :-)
I've got a winforms app that I developed to do batch processing on tens of thousands of students, now we're trying to run it nightly as a scheduled task.
I personally find it useful to be able to login to the box and see how it's processing by looking at the GUI, though the standard way it to convert it into a commandline app.(which radically limits the amount of screen realestae I can use for loggin messages)
Can I run the app as a schedueld task, the IT Guy whos scheduling says it's not running because it's a winform app. Are there any tricks needed to get it to run well, or am I forced to rewrite it as a commandline app with it's 80 char width limit.
Basicaly I just echo the log file to the screen in realtime to make debugging issues easier. So the gui is output only.
Its' running as the currently loggedin user, but the issue is that it does not run if the user is not currently logged in on the box,so when we leave for the night it fails to run.
Thanks,
Eric-
You need to make sure it is running as the currently logged in account. If it runs as 'system' I don't think it will show up correctly.
I have one of these myself... and despise it. It only exists because I haven't had a chance to rewrite it into a proper service. Don't forget there are more ways to log than just outputting to the console. ;)
I have a very critial business application presently running using Winforms.
The application is a very core UI shell. It accepts input data, calls a webservice on my server to do the computation, displays the results on the winforms app and finally send a print stream to the printer.
Presently the application is deployed using Click-once.
Moving forward, I am trying to contemplate wheather I should move the application into a Silverlight application. Couple of reasons I am thinking silverlight.
Gives clients the feel that it is a cloud based solution.
Can be accessed from any PC. While the clickonce app is able to do this as well, they have to install an app, and when updates are available they have to click "Yes" to update.
The application presently has a drop down list of customers, this list has expanded to over 3000 records. Scrolling through the list is very painful. With Silverlight I am thinking of the auto complete ability.
Out of the browser - this will be handy for those users who use the app daily.
I haven't used Silverlight previous hence looking for some expert advice on a few things:
Printing - does silverlight allow sending raw print data to the printer. The application prints to a Zebra Thermal label printer. I have to send raw bytes to the printer with the commands. Can this be done with SL, or will it always prompt the "Print" dialog?
Out of browser - when SL apps are installed as out of browser, how to updates come through, does the app update automatically or is the user prompted to opt for update?
Printing -- using the PrintDocument API your user will be prompted for a print dialog. Currently using that API there is no way to suppress this. It isn't ideal for high-volume thermal situations (like pharmacies, shipping warehouses, etc.). You could use the trusted application mode and peek out into COM and do whatever you want with the printer.
The update happens when the application asks for it. There is an API to use and, once called, if an update exists it is downloaded -- no prompt to the user as an option. If an update is found you can alert the user to restart or that on the next restart they will have the updated application.
Autocomplete is not something that can only be done in Silverlight. Your ClickOnce app is already out-of-browser. And printing via raw bytes to a thermal printer is something that would not be easily engineered in Silverlight.
Not trying to sound negative, but in sum it sounds like you're better off simply working on enhancing the app that you already have.
Anybody here has actually implemented any logging strategy when application is running as XBAP ? Any suggestion (as code) as to how to implement a simple strategy base on your experience.
My app in desktop mode actually logs to a log file (rolling log) using integrated asop log4net implementation but in xbap I can't log cause it stores the file in cache (app2.0 or something folder) so I check if browser hosted and dont log since i dont even know if it ever logs...(why same codebase)....if there was a way to push this log to a service like a web service or post error to some endpoint...
My xbap is full trust intranet mode.
I would log to isolated storage and provide a way for users to submit the log back to the server using either a simple PUT/POST with HttpWebRequest or, if you're feeling frisky, via a WCF service.
Keep in mind an XBAP only gets 512k of isolated storage so you may actually want to push those event logs back to the server automatically. Also remember that the XBAP can only speak back to it's origin server, so the service that accepts the log files must run under the same domain.
Here's some quick sample code that shows how to setup a TextWriterTraceListener on top of an IsolatedStorageFileStream at which point you can can just use the standard Trace.Write[XXX] methods to do your logging.
IsolatedStorageFileStream traceFileStream = new IsolatedStorageFileStream("Trace.log", FileMode.OpenOrCreate, FileAccess.Write);
TraceListener traceListener = new TextWriterTraceListener(traceFileStream);
Trace.Listeners.Add(traceListener);
UPDATE
Here is a revised answer due to the revision you've made to your question with more details.
Since you mention you're using log4net in your desktop app we can build upon that dependency you are already comfortable working with as it is entirely possible to continue to use log4net in the XBAP version as well. Log4net does not come with an implementation that will solve this problem out of the box, but it is possible to write an implementation of a log4net IAppender which communicates with WCF.
I took a look at the implementation the other answerer linked to by Joachim Kerschbaumer (all credit due) and it looks like a solid implementation. My first concern was that, in a sample, someone might be logging back to the service on every event and perhaps synchronously, but the implementation actually has support for queuing up a certain number of events and sending them back to the server in batch form. Also, when it does send to the service, it does so using an async invocation of an Action delegate which means it will execute on a thread pool thread and not block the UI. Therefore I would say that implementation is quite solid.
Here's the steps I would take from here:
Download Joachim's WCF appender implementation
Add his project's to your solution.
Reference the WCFAppender project from your XBAP
Configure log4net to use the WCF appender. Now, there are several settings for this logger so I suggest checking out his sample app's config. The most important ones however are QueueSize and FlushLevel. You should set QueueSize high enough so that, based on how much you actually are logging, you won't be chattering with the WCF service too much. If you're just configuring warnings/errors then you can probably set this to something low. If you're configuring with informational then you want to set this a little higher. As far as FlushLevel you should probably just set this to ERROR as this will just guarantee that no matter how big the queue is at the time an error occurs everything will be flushed at the moment an error is logged.
The sample appears to use LINQ2SQL to log to a custom DB inside of the WCF service. You will need to replace this implementation to log to whatever data source best suits your needs.
Now, Joachim's sample is written in a way that's intended to be very easy for someone to download, run and understand very quickly. I would definitely change a couple things about it if I were putting it into a production solution:
Separate the WCF contracts into a separate library which you can share between the client and the server. This would allow you to stop using a Visual Studio service reference in the WCFAppender library and just reference the same contract library for the data types. Likewise, since the contracts would no longer be in the service itself, you would reference the contract library from the service.
I don't know that wsHttpBinding is really necessary here. It comes with a couple more knobs and switches than one probably needs for something as simple as this. I would probably go with the simpler basicHttpBinding and if you wanted to make sure the log data was encrypted over the wire I would just make sure to use HTTPS.
My approach has been to log to a remote service, keyed by a unique user ID or GUID. The overhead isn't very high with the usual async calls.
You can cache messages locally, too, either in RAM or in isolated storage -- perhaps as a backup in case the network isn't accessible.
Be sure to watch for duplicate events within a certain time window. You don't want to log 1,000 copies of the same Exception over a period of a few seconds.
Also, I like to log more than just errors. You can also log performance data, such as how long certain functions take to execute (particularly out-of-process calls), or more detailed data in response to the user explicitly entering into a "debug and report" mode. Checking for calls that take longer than a certain threshold is also useful to help catch regressions and preempt user complaints.
If you are running your XBAP under partial trust, you are only allowed to write to the IsolatedStorage on the client machine. And it's just 512 KB, which you would probably want to use in a more valuable way (than for logging), like for storing user's preferences.
You are not allowed to do any Remoting stuff as well under partial trust, so you can't use log4net RemotingAppender.
Finally, under partial trust XBAP you have WebPermission to talk to the server of your app origin only. I would recommend using a WCF service, like described in this article. We use similar configuration in my current project and it works fine.
Then, basically, on the WCF server side you can do logging to any place appropriate: file, database, etc. You may also want to keep your log4net logging code and try to use one of the wcf log appenders available on the internets (this or this).