Talk:Assembly (CLI)

Latest comment: 12 years ago by BrainSlugs83 in topic Incorrect information

Dubious edit

This article claims that "the Just-in-time compiler compiles the code in an assembly into CIL, which is then compiled into machine language at runtime by the CLR". As far as I know, this is incorrect: CIL code is generated by the compiler for the .NET language (such as Visual Basic or C#), and the resulting CIL bytecode is stored in the assembly. The JIT compiler then compiles it into native code during execution. The statement seems to have the two different compilers mixed up. - Sikon (talk) 06:38, 11 December 2007 (UTC)Reply

Thanks for pointing that out. --soum talk 07:28, 11 December 2007 (UTC)Reply

=+=+=+ Article mentions "Fusion" ... never heard of it. "That assembly (say, lib.dll) will contain the neutral resources (which Microsoft says is International English, but implies to be US English)." Does that mean the main assembly uses US English? What does this have to do with anything? Unclear and unfocused, not to mention lousy grammar( "implies" lol). <Satellite assemblies make available the data to allow the use of local strings, language and customary practices overriding the defaults found in the neutral resources> - If I knew that what I just wrote correctly describes satellites, I'd add it. But I won't because I had never heard of the term before a few minutes ago. Needs a rewrite, please.69.40.254.72 (talk) 14:43, 19 November 2010 (UTC)Reply

assembly signing and hacking edit

re "But what happens if the crackers uses an own pair of public and private key, who guarantees you the public key in the dll is the correct one? "

.Net applications usually load assemblies by their strong name. The strong name includes (in effect) the public key of the assembly. The exploit of substituting a different public key wouldn't work, because it would change the strong name of the assembly, and thus would not be loaded by the caller. Loading by strong name isn't absolutely required, but is common, and required if you want a secure app. Leotohill (talk) 17:09, 23 January 2008 (UTC)Reply

Change of name edit

I think that we should call this article "Assembly (Common Language Infrastructure)" or "Assembly (CLI)" because it feel more right when it actually is a part of the Common Language Infrastructure standards and not just present in .NET framework. However we should keep a redirection page and saying that it is usually refered to as a ".NET assembly". Does anyone agree to this? Robert Sundström (talk) 18:08, 19 February 2010 (UTC)Reply

The term ".NET code" should maybe be "managed code" or "CLI code". Robert Sundström (talk) 21:19, 20 February 2010 (UTC)Reply
Agreed that this should be renamed "Assembly (Common Language Infrastructure)". I do not think that the term ".NET code" should be replaced with "managed code" because that would also include Java code, which doesn't apply. I like Sundström's second idea of replacing it with "CLI code". —Preceding unsigned comment added by 204.8.148.32 (talk) 17:54, 16 March 2011 (UTC)Reply

Assemblies versions edit

The article says: "However, this does not eliminate all possible versioning conflicts between assemblies[3]".

However, this link appears to be about difficulties in resolving namespaces, not resolving assemblies. The author of the linked article notes that namespace issues required his developers to change their assemblies by embedding the ambiguously-namespaced-referenced-assembly within multiple consumer-assemblies.

But, being unable to resolve a namespace because it is used by multiple referenced assemblies is very different than being unable to resolve an assembly. I don't think the quoted article sentence is necessary or relevant to this article. —Preceding unsigned comment added by 204.8.148.32 (talk) 17:50, 16 March 2011 (UTC)Reply

Dead link edit

During several automated bot runs the following external link was found to be unavailable. Please check if the link is in fact down and fix or remove it in that case!

  • http://devhawk.net/2008/09/17/DLR+Namespace+Change+Fire+Drill.aspx
    • In .NET assembly on 2011-05-20 22:29:20, Socket Error: 'A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond'
    • In .NET assembly on 2011-05-31 13:13:02, Socket Error: 'A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond'

--JeffGBot (talk) 13:13, 31 May 2011 (UTC)Reply

Incorrect information edit

In the opening paragraph: "Visual Studio however does not support using different languages in one assembly." -- from experience I believe this statement to be incorrect. We did this with Visual Studio 2005 (in 2005) when developing an ASP.NET website -- with special web.config entries I remember we were able to allow one set of folders to contain C# code while another contained VB.NET code, all in one Visual Studio project (and one Solution of course). Since there is no reference, I think this sentence should probably be removed. BrainSlugs83 (talk) 02:12, 28 February 2012 (UTC)Reply