|
Hi there,
I plan to create a menu interface program for CD/DVD that uses classes from .NET Framework 2.0. There are some powerful classes in .NET that I want to use instead of creating them by myself to reduce the developing time.
This menu program should be started automatically when the user inserts the CD/DVD in the drive. This is done by using the AutoRun technology in Windows. The problem is that if .NET Framework 2.0 is not installed in the computer this program can not be started. Then the user must first install .NET Framework 2.0 before the program can be run. Well, this is a common problem to all .NET programs and normally maybe this is not a big problem, but this program is supposed to show a menu interface immediately, and, I guess most users expect that, always...
I know that Windows Vista always have .NET Framework 2.0 installed and I guess most Windows XP users today also have it. But I have never found any statistics about this.
Does anybody know an Internet site that have statistics about how many people that uses .NET Framework 2.0, and the other versions of .NET Framework? Does Microsoft have some statistics?
/Mika
|
|
|
|
|
I would still say that you'd be crazy to assume everyone has .NET. Just write a bootstrapper that installs it from your CD.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Yes. I will of course check if NET Framework is installed, as the first thing I do, and start an installation if not. But I am just worried it will take a very long time. NET Framework is big and people expects a menu appear immediately.
But I have to do some tests and see how long time it will take. And see how the user experience is if they need to wait long time before the menu appears.
|
|
|
|
|
The only thing that can really be assumed: All Windows Vista and above OS will have at least .NET 3.0. Unfortunately, Microsoft has not pushed .NET 2.0 or .NET 3.0 to older systems through either Windows Updates or Service Packs.
Regards,
Thomas Stockwell
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Visit my Blog
|
|
|
|
|
It would be interesting to know how many percent of for example the Windows XP users really have NET 2.0 installed, but there are maybe no official statistics here to read. But I guess the number of people having NET 2.0 or above is increasing very fast, because more and more program uses it and installs it. And in Vista it is always included (as part of 3.0).
|
|
|
|
|
Hello all, I have some wierdness.
using the very simple code below:
EventLog el = new EventLog("Security");
foreach (EventLogEntry elr in el.Entries)
{
Trace.WriteLine(elr.Message);
}
results with the following message:
The description for Event ID '4647' in Source 'Microsoft-Windows-Security-Auditing' cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them. The following information is part of the event:'S-1-5-21-51003140-4199384537-3980697693-500', 'Administrator', '26L2233A1-06', '0x86377'
As far as I can tell, it's like the .net framework can't find the source dll to resolve the message. I pulled out some old C++ code that did some event log processing and ran it on the same machine and sure enough I couldn't find the message DLL.
I know that Microsoft changed the event log API in vista/2008 but I thought the new API was backwards compatible.
Backwards compatible or not, I need to be able to read the security log on vista/2008.
Any ideas?
thanks,
Gene
|
|
|
|
|
Can you read other logs? Application, System, DNS, FRS etc?
There isn't an API (in the Win32 SDK function sense) to read the text details from the event logs. Your C++ code is probably reading the MessageFile setting from the appropriate place in the registry, and doing a Loadlibrary / FormatMessage dance.
That won't work on Vista / 2K8. The message DLLs are referenced in a different way (look at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers). If the .NET framework only uses the "old" way, you'll have to roll your own.
|
|
|
|
|
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
|
|
|
|
|