I'm having a problem with making my VB.NET application point to something rather than "Application" in Event Log...
I create my custom event log using the function: EventLog.CreateEventSource("My_Source_Name", "My_Log_Name")
where the first parm is the Source Name, and the second parm is the log name. This method works every time it creates the event log's source, but when I'm about to add a new entry, I'm surprised that for some sources the process write the log under my custom log, but for other sources, the log is written in Application!!! (Some times with an error at it's header)!!!!!
I need to know, what exactly is going on?? am I (somehow) following the right way?? if Yes, what are the enhancements that I need to add to my code to make it look much better?? how can I stop this from occurring again so I can have all my logs under my customized log name?? and if No, what is the right way of doing this?? and is there any other way of writing this code (even if the new code was for another solution rather than the event log)??
Thank you very much :)
"To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges."
http://msdn.microsoft.com/en-us/library/5zbwd3s3.aspx
On the other hand, you should have a class (or interface) in charge of logging as a vertical layer on your application. That class is the one in charge of internally write to the appropriate event source.
However, if you need something powerful I really recommend Log4Net.
http://logging.apache.org/log4net/
Related
Consider for example this modified Simple TCP sample program:
How can I display the current state of the program like
Wait for Connection
Connected
Connection terminated
on the frontpanel, depending on where the "data flow" currently is.
The easiest way to do this is to place a string indicator on your front panel and write messages to a local variable of this indicator at each point where you want to see a status update.
You need to keep in mind how LabVIEW dataflow works: code will execute as soon as the data it depends on becomes available. Sometimes you can use existing structures to enforce this - for example, if you put a string constant inside your loop and wire it to a local variable terminal outside the loop, the write will only happen after the loop exits. Sometimes you may need to enforce that dataflow artificially, for example by placing your operation inside a sequence frame and connecting a wire to the border of the sequence: then what's inside the sequence will only happen after data arrives on that wire. (This is about the only thing you should use a sequence for!)
This method is not guaranteed to be deterministic, but it's usually good enough for giving a simple status indication to the user.
A better version of the above would be to send the status messages on a queue or notifier which you read, and update the status indicator, in a separate loop. The queue and notifier write functions have error terminals which can help you to enforce sequence. A notifier is like the local variable in that you will only see the most recent update; a queue keeps all the data you write to it in the right order so would be more suitable if you want to log all the updates to a scrolling list or log file. With this solution you could add more features: for example the read loop could add a timestamp in front of each message so you could see how recent it was.
A really good solution to this general problem is to use a design pattern based on a state machine. Now your program flow is clearly organised into different states and it's very easy to add in functionality like sending a different message from each state. There are good examples and project templates for these design patterns included with recent versions of LabVIEW.
You should be able to find more information on any of the terms in bold in the LabVIEW help or on the NI website.
Is it possible to replay all failed messages through nServiceBus without using ServiceControl/ServicePulse?
I'm using NServiceBus.Host.exe to host our endpoints. Our ServiceControl/ServicePulse database became corrupt. I was able to recreate it, but now I a few failed messages in our SQL database which are not visible through the ServicePulse.
Will this help?
Take a look at the readme.md
For people who want the functionality that this tool previously
provided please take one of the following actions
Return to source queue via either ServiceInsight or ServicePulse.
Return to source queue using custom scripting or code. This has the
added benefit enabling possible performance and usability
optimizations since, as the business owner, you have more context as
to how your error queue should be managed. For example using this
approach it is trivial for you to choose to batch multiple sends
inside the same Transaction. Manually return to source queue via any
of the MSMQ management tools. If you still want to use
MsmqReturnToSourceQueue.exe feel free to use the code inside this
repository to compile a copy.
You can look at the link provided to build your own script (to mach SQL) and trip the error message wrapper so you can push the stripped message back to the SQL queue.
Does this help?
If not please contact support at particular dot net and we will be glad to help :-)
There is nothing built into the Particular stack that I know of that will take care of this.
When I have ran into issues like this before I will usually setup a console application to send some commands into the endpoint and then setup a custom handler in the endpoint to fix the data inconsistencies. This allows you to test the "fix" in a dev/uat environment and then you have an automated solution for production to fix the problem.
This question references some events raised by the VBIDE. I'm looking for an event I can hook that is raised whenever an Access object is saved (form, querydef, module, class module, etc.).
If such an event is unavailable, I'm looking for workarounds. A project-wide save event or a code module change event would be acceptable alternatives. Perhaps there is some creative way to be notified when one of the "msys" system tables is updated and, ideally, which row.
Worst-case scenario, it looks like I can iterate through the CurrentDb.QueryDefs .LastUpdated or CurrentProject.AllForms/.AllModules/.AllReports .DateModified property and just poll it on some interval, but I would like to avoid that if possible.
There aren't any events that you can catch, but there is probably a better solution than polling the database objects.
The Database Window (that contains all of the tables, queries and other objects) will receive Windows messages when certain things happen in the User Interface. A quick look with Spy++ shows that the Database Window appears to receive a WM_ENABLE message when an object is saved. If you can trap that message using Win32, you might have the beginnings of a reliable "event".
Note that VBA UserForms can be used in Access Projects, but they don't appear in the Database Window, so that might be a problem.
Also, anything that programmatically changes/adds/deletes database objects might not trigger an automatic Database Window refresh or message.
I have a very odd situation in my SharePoint staging environment. We recently stood up a new SharePoint 2010 server (single WFE + a DB server), and attached a backed-up content database from our existing environment. We created a new web application, and pointed it at the attached content database. All of our site collections, sites, lists, etc. appeared, and things appeared good.
We had deployed some custom content types to our existing environment prior to moving the database, and we wanted to upgrade those content types. Specifically, we attach event receivers to the content types (using code, not XML) and we needed to update the assembly version that those event receivers point to. So we ran our usual code (part of a feature receiver) to remove the event receivers, but to our surprise, the receivers remained.
In an attempt to remedy the situation, we wrote a console application that iterates over all content types (SPWeb.ContentTypes) in the root site of each site collection and deletes them, and then calls SPContentType.Update(true) on each content type. There are no errors returned from the call to Update, but again to our even greater surprise, SharePoint still reports the event receivers are attached.
In a desparate last ditch effort, we even went into the content database (after taking a snapshot -- and remember, this is staging, not production!) and manually DELETED the offending receivers from the EventReceivers table. We figured that should have at least some kind of effect. Alas, SharePoint still reports the receivers as being present.
We perform these types of upgrades on content type event receivers all the time, but have never run into this issue on any other SharePoint farm. Does it sound like an environmental problem? Is it something that could have been caused by moving the content database? Any help would be appreciated, because we are completely stumped at this point.
1st of all, I will never recommend changing anything in DB. It will surely give you trouble in long run.
You did mention that you tried to remove the event reciever from Web level but not sure if you have tried removing it from List/Library level
Use ContentTypeUsage class and try deleting from List/Library level
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spcontenttypeusage.aspx
I have a small VB .Net application that, among other things, attempts to substitute system wide typed text by the user(hotstrings concept). To achieve that, I have deployed 'ahk2exe' and 'AutoHotkeySC.bin' with my application and did the following:
When a user assignes a new 'hotstring':
Kill 'hotstring' exe script file if running
Append new hotstring to the script file (if non exist then create a new one)
Convert edited/new script file to exe (using ahk2exe)
Run the newly converted script exe
(somewhere there I also check if the hotstring has been already assigned)
However, I am not totally satisfied with this method for the following two main reasons:
The extra resources deployed with the application.
Lag: The time it takes for the system to kill the process and then restart it takes a minimum of 5 seconds on my fast computer and more on other computers. That amount of time is much more than the time it takes the user to assign the hotstring, minimize/close the window and then test his/her new hotstring. When the user does so initially with no success they will think the process failed. So this method is not very good for user experience.
So, I am looking for a different method or implementation. May be using keyboard hooks? Or maybe adding a .dll library that achieves the same. Are there any resources you know about that might help (free or commercial)? What is the best way to achieve my desired goal?
Many thanks for your help.
Implementing what Autohotkey does would be a pretty non trivial task.
But I'm pretty sure that AHK supports an "autoreload" option for scripts
googling "autohotkey auto reload" turned up several pages discussing that very concept. IF that worked, all you'd have to do is update the script file and that's it, AHK should automatically reload the script.