ASP.NET - what are assemblies and how do they work?



  • so, after reading through blog post (and other related/linked from it) in this thread, and adding it up to my list of frustrating things about/in php and projects i wrote/maintained in it, i decided i want to try something else and went to try out ASP.NET, with C# (as i already knew that from xna programming). i have run to some difficulties understanding the overall app infrastructure (as i've been working with php which had none and every framework did things its way), such as routing (figuring it out), server-client communication, AND assemblies

    i know how to read and i will look into it, but right now i just need to get some basic concept of what they are. and what they're for to be able to work with them at a minimum basic level.
    from what i've grasped so far, it seems to me they're an equivalent of php_ini part there various php modules were turned on/off. offcourse, in php these were server-wide settings, and in ASP.NET they're local (application scope), so that's why they're there in web.config . The granularity is bigger, so the "modules" are essentially .NET namespaces. Do i understand correctly? What (more) do I need to know about them (again, not for an in-depth knowledge, just for the basic ability to use them correctly and efficiently, i'll study the details later).

    I'll be thankful for any links, and maybe one or two brief explanations would be a nice bonus.

    [offtopic]
    why can't chrome display community server's wysiwyg post editor? yes, i know, cs sucks, but i'm curious about more exact explanation, any psychic-debugging/educated guesses?



  • @SEMI-HYBRID code said:

    why can't chrome display community server's wysiwyg post editor? yes, i know, cs sucks, but i'm curious about more exact explanation, any psychic-debugging/educated guesses?
     

    My guess?

    if (detected browser in (tiny list of known browsers)) {
      use tinyMCE;
    }
    else {
      fuck you;
    }



  • At the level of abstraction that's relevant, an assembly is a .dll file*. It can contain classes and resources. It has a fully qualified name which is made up from the filename and various metadata. Each of the projects in your solution will compile to one assembly.

    * Yes, I know that's not strictly true, but IMO it's the right level of simplification for developing an ASP.Net site.



  • From Microsoft's .NET 4.0 C# training manual

    When you compile a Visual C# application by using Visual Studio 2010, the compiler generates an executable file that the CLR can run. This file is called an assembly. An assembly contains code in an intermediate format called Microsoft intermediate language (MSIL). All compilers for the .NET Framework generate code in this format, regardless of the programming language that was used to write an application. This enables the CLR to run code in the same way, regardless of the language that the developer used.

    Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, and security.

    You can think of an assembly as a collection of types and resources that work together and form a logical unit of functionality. An assembly provides the CLR with the information that it needs to be aware of type implementations.

    An assembly can be of two types: an executable program, or a library that contains executable code that other programs can reuse. By using a library, developers can modularize the development of their applications into logical components.

    Typically, when you are distributing assemblies to customers as part of your application, you will want to ensure that the assembly contains versioning information, and that the assembly is signed.

    Versioning your assemblies is important because ultimately, any applications that you build will have multiple releases. Versioning information can help you identify which versions customers already have and enable you to perform the necessary steps to upgrade the application. Similarly versioning information can also help when documenting and fixing bugs.

    Signing your assemblies is equally important because it ensures that your assembly cannot easily be modified or replaced by an alternative implementation from a malicious source, and because it gives the assembly a strong name.

    [snip]

    Additional Reading

    For more information about the purpose and features of assemblies, see the Assemblies in the Common Language Runtime page at http://go.microsoft.com/fwlink/?LinkId=192879.

    For more information about assembly versioning, see the Assembly Versioning page at http://go.microsoft.com/fwlink/?LinkId=192880.

    For more information about assembly signing, see the SignTool.exe (Sign Tool) page at http://go.microsoft.com/fwlink/?LinkId=192881.



  • @dhromed said:

    @SEMI-HYBRID code said:

    why can't chrome display community server's wysiwyg post editor? yes, i know, cs sucks, but i'm curious about more exact explanation, any psychic-debugging/educated guesses?
     

    My guess?

    if (detected browser in (tiny list of known browsers)) {
      use tinyMCE;
    }
    else {
      fuck you;
    }

    Yes, TinyMCE whitelists browsers. Or it least it did several years ago, which is the last time I used it. However, CS is using a similarly old version.



  • @morbiuswilters said:

    Yes, TinyMCE whitelists browsers.

    Any reason why that is?

    I thought the standard for compatibility tests within Javascript revolved around object/method detection (or abstraction via some framework), rather than browser detection.


  • ♿ (Parody)

    @Cassidy said:

    @morbiuswilters said:
    Yes, TinyMCE whitelists browsers.

    Any reason why that is?

    Software sucks?

    @Cassidy said:

    I thought the standard for compatibility tests within Javascript revolved around object/method detection (or abstraction via some framework), rather than browser detection.

    Best practices have never caused a want of subject matter for this site.



  • @boomzilla said:

    Software sucks?

    Well, yes.. no argument there, but being more accurate: some software sucks because something in the process that bought about that software is flawed ...

    @boomzilla said:

    Best practices have never caused a want of subject matter for this site.

    .. they haven't; again, true.

    I just find it surprising that something so widely-used and pretty transparent would contain such outdated WTFs as browser detection code.[1]

    [1]Oh, this is NOT ammo to begin another OS war, open-source analysis and debate about WTF frameworks, etc. It's just an observation.



  • @Cassidy said:

    @boomzilla said:

    Best practices have never caused a want of subject matter for this site.

    .. they haven't; again, true.

    I just find it surprising that something so widely-used and pretty transparent would contain such outdated WTFs as browser detection code.[1]

    [1]Oh, this is NOT ammo to begin another OS war, open-source analysis and debate about WTF frameworks, etc. It's just an observation.

    CS is using a version from like 2007. The current version may no longer whitelist browsers. You are asking stupid questions for a reader of this site.



  • @blakeyrat said:

    CS is using a version from like 2007.

    I thought feature-sniffing replaced browser-detection way before that. I recall articles espousing the evils of relying on "document.layers" and "document.all" to distinguish between IE4 and NN, advocating feature-sniffing techniques instead.

    @blakeyrat said:

    The current version may no longer whitelist browsers.

    Perhaps, but my point was that javascript written newer than 2003 generally doesn't do browser-detection.

    @blakeyrat said:

    You are asking stupid questions for a reader of this site.

    You're free not to answer them.



  • @Cassidy said:

    @blakeyrat said:

    You are asking stupid questions for a reader of this site.

    You're free not to answer them.

    True, but I mostly just wanted to call you stupid.



  • @Cassidy said:

    I just find it surprising that something so widely-used and pretty transparent would contain such outdated WTFs as browser detection code.[1]

    Yes with a but. Some stuff still uses browser-detection so it can deliver an optimized version of the Javascript to the browser, without feature tests and degraded functionality for all browsers built-in. I know Google does this quite a bit. Also, I don't consider feature testing to be significantly better than UA sniffing. Both are subject to failing catastrophically if confronted with browsers they don't anticipate. Really, you have to be diligent about keeping on top of software updates, it's the only way to be sure.



  • @morbiuswilters said:

    Also, I don't consider feature testing to be significantly better than UA sniffing. Both are subject to failing catastrophically if confronted with browsers they don't anticipate.

    But the point of UA sniffing is usually to match browser capabilities to deliverable functionality (analytics notwithstanding), which feature-detection tends to do better. I agree that the fall-though often defaults to the older core version rather than being newer-aware; I'm just of the opinion that UA-sniffing is asking the wrong question when trying to deliver code optimised for the browser.

    The name and version of the browser really is incidental to its capabilities.

    Anyway, a minor point. Moar whisky required...


Log in to reply