|
Thank you Graham,
I can read the application log correctly but that's probably because they are registering their message dlls in the old NT way instead of the new vista way.
I found the key that you reference, but couldn't find the "GUID" in the event log entry so I couldn't figure out the correct message dll to do the load/format message.
I couldn't find any documentation on all this mess; can you point me some?
thank you again,
gene
|
|
|
|
|
Getting further, maybe the problem is that thre isn't a key for "Microsoft-Windows-Security-Auditing" in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels
hive.
I guess I could just enumerate the all the publishers values and look for the value "Microsoft-Windows-Security-Auditing" to get the message dll name.
I'll try that next. 
|
|
|
|
|
well...I'm getting closer but I can't figure out how to get a "real" event ID for the security log.
for example,
Here is a sample event in C#:
EntryType SuccessAudit
EventID 0x00001210
Source "Microsoft-Windows-Security-Auditing"
now, I've figured out that the REAL event ID that the Vista Event API wants is -1342172656 or 0xB0001210, so the piece that I'm missing is the 0xB000???? path.
according to this http://msdn.microsoft.com/en-us/library/aa385646(VS.85).aspx it says that I'm suppose to shift the EntryType left by 30 but the EVENTLOG_AUDIT_SUCCESS is 8 so shifting it 30 bits slides it right off the DWORD.
Does anyone know how to turn a EventLogEntry into a Message DLL ID? I THINK it's all related that I can't figure out the facility and severity correct.
thank you for any help,
Gene
|
|
|
|
|
How can I be sure that an assembly is CLS-compliant?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Do you mean, apart from checking if it's got the CLSCompliant(true) attribute?
Regards,
Lev
|
|
|
|
|
Yes. FXCOP says I should use the attribute if the assembly is CLSCompliant, but how do I know if it is?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I think you have two options:
1. Add the [assembly:CLSCompliant(true)] attribute to the assembly, and see what are the compiler's errors/warnings
2. Or if you need to do it in code, look at the CLS compliance restrictions in the ECMA 335 standard[^] (it's got a lot of info on CLS compliance) and check for these using Microsoft.Cci (the fxcop's backend) or Mono.Cecil
Regards,
Lev
|
|
|
|
|
Lev Danielyan wrote: Add the [assembly:CLSCompliant(true)] attribute to the assembly, and see what are the compiler's errors/warnings
Yep, I did that and didn't get any errors or warnings.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Then you are safe to mark it with CLSCompliant attribute 
Regards,
Lev
|
|
|
|
|
BTW, check out this article[^]
Regards,
Lev
|
|
|
|
|
My understanding is that you should mark the attribute if you intend it to be CLS compliant and then compiler will let you know if it isn't.
Look here for more info.
-Joe.
|
|
|
|
|
That's what I said in my previous post. But I think it is more challenging to analyze the assembly and figure out if it is CLS compliant.
Regards,
Lev
|
|
|
|
|
"More challenging" = "more time-consuming".
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Right, but it will give more knowledge on the guts of .Net, and eventually you will be writing compliant code right away (of course in those cases when you actually can make your assembly compliant), it can make some time savings as opposed to marking your stuff with attribute and fixing errors (especially for large products).
But this is just IMHO 
Regards,
Lev
|
|
|
|
|
Of course, with all the rules turned on, I get over 70 "issues". When I turn off the rules I don't really care about (variable naming, portability, and globalization), I end up with just 34 issues. There's only one that kinda bothers me, and it concerns "strongly named" assemblies, and security permissions.
0) For strongly named assemblies, it says I need a key. Where do I get the key? How do I make one myself? For an ILMerged (or obfuscated) assembly do I still have to strongly name each of the merged assemblies, or just the resulting EXE file?
1) For security permissions, how do I determine which ones I need? Is there a generic setting I can use?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: Where do I get the key? How do I make one myself?
Use sn -K myKey.snk and add this into your AssemblyInfo.cs file:
assembly:AssemblyKeyFileAttribute(@"c:\path to keyfile\myKey.snk")] You can apply strong naming as granularly as you want - be it assembly or resulting exe.
|
|
|
|
|
I see no reason to strongly name an assembly in articles here (it appears as if it should be left to someone that implements the code in their own projects. Is that a correct outlook?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
My understanding of things is ...
There are 2 types of assemblies: private and shared: Private are placed in the same directory as the application, they do not need to be signed. Shared are installed in the GAC (Global Assembly Cache), they must be signed.
The .NET runtime uses the combination of assembly name, version and public key as a unique key for each assembly, this unique key is called the strong name.
As Pete mentioned, the key is generated by you. By keeping the private key private you prevent others from spoofing your assembly. If you manage final approval for assemblies in your company you may also want to look at 'delayed signing' which allows you to sign with the public key (for testing), and then add the private for release.
As to whether you should sign your article assembly ... If you are going to maintain it and expect it to be used as is, then i'd say yes. If you intend it to illustrate the concepts in the article and expect people to integrate the ideas into their own assemblies, then i'd say no ... i'd expect no.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
A little bit off-topic, but you may find also StyleCop[^] interesting.
|
|
|
|
|
The Gendarme[^] is also good, and open-source too
Regards,
Lev
|
|
|
|
|
Looks like it requires source code changes to work. I'm not inclined to do that.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Gendarme doesn't, it is pure assembly (MSIL) analysis, just like FXCop, but the difference is that gendarme is based on open-source Mono.Cecil library, whereas the Microsoft.Cci (which is actually very good by itself) is not redistributable apart from fxcop. At least it wasn't last time I checked (two or three months ago)
Regards,
Lev
|
|
|
|
|
Ah that thing drove me nuts :P
|
|
|
|
|
Hopefully in a good way... although (pea)nuts are good especially at Christmas time and with raisins
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
