|
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
|
|
|
|
|
I have .NET 2.0 client code attempting to negotiate an SSL session with stunnel. stunnel is currently configured to allow SSL3 connections.
A call to AuthenticateAsClient, exclusively supplying SslProtocols.Ssl3 will succeed.
So far, all working as I'd expect
I want the .NET client to retrograde the SSL version when it connects to a server offering an older algorithm. The SslProtocols is a flag-attributed enumeration. I'd expect to pass multiple protocol versions like so:
sslstream.AuthenticateAsClient(Host, ClientCertificates, SslProtocols.Ssl2 | SslProtocols.Ssl3 | SslProtocols.Tls, true);
However, the above method call results in the following .NET exception & stunnel log trace:
Client-side Exception:
System.IO.IOException:
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
Server-side Log
2008.12.19 10:40:50 LOG7[5600:10944520]: pop3s accepted FD=10 from 192.168.20.6:3293
2008.12.19 10:40:50 LOG7[5600:11063160]: pop3s started
2008.12.19 10:40:50 LOG7[5600:11063160]: FD 10 in non-blocking mode
2008.12.19 10:40:50 LOG7[5600:11063160]: TCP_NODELAY option set on local socket
2008.12.19 10:40:50 LOG5[5600:11063160]: pop3s accepted connection from 192.168.20.6:3293
2008.12.19 10:40:50 LOG7[5600:11063160]: SSL state (accept): before/accept initialization
2008.12.19 10:40:50 LOG3[5600:11063160]: SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
2008.12.19 10:40:50 LOG5[5600:11063160]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2008.12.19 10:40:50 LOG7[5600:11063160]: pop3s finished (0 left)
When I omit SslProtocols.Ssl2 from the parameter value, it results in a different condition.
Client-side Exception:
System.Security.Authentication.AuthenticationException:
A call to SSPI failed, see inner exception.
---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
--- End of inner exception stack trace ---
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
So I guess my question is: Is it misconfiguration of my behalf, or do I need to manually crank code to manage the protocol retrogradation?
Many thanks, Ian.
|
|
|
|
|
I can get WindowsIdentity with this Function:
[DllImport("advapi32.dll", CallingConvention = CallingConvention.StdCall)]
public static extern bool LogonUser(string lpszUsername,
string lpszDomain, string lpszPassword, int dwLogonType,
int dwLogonProvider, ref IntPtr phToken);
private static WindowsIdentity getWindowsIdentity(string userName, string Domain, string Password)
{
bool posix = ((int) Environment.OSVersion.Platform == 128);
WindowsIdentity user = null;
try
{
if (posix)
{
user = new WindowsIdentity(userName);
}
else
{
IntPtr token = IntPtr.Zero;
LogonUser(userName, Domain, Password, 2, 0, ref token);
if (token == IntPtr.Zero)
{
return null;
}
user = new WindowsIdentity(token);
}
}
catch (Exception ex)
{
return null;
}
return user;
}
But I want to get WindowIdentity with only Domain\UserName argument?
Thanks for any idea !
QuynhTD
|
|
|
|
|
Wow. That's alot of code to do this:
string userName = Environment.UserName;
string userDomain = Environment.UserDomainName;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
