locked
Lack of GACable entry for Microsoft AntiXSS Assembly (Bug in Library?) RRS feed

  • Question

  • I am trying to use Microsoft AntiXSS Assembly in my application to quickly fight against bad characters. When I see the project the assembly is being referenced as below:

    <Reference Include="HtmlSanitizationLibrary">
          <HintPath>..\..\..\..\Program Files (x86)\Microsoft Information Security\AntiXSS Library v4.2\SANITIZER\HtmlSanitizationLibrary.dll</HintPath>
    </Reference>

    and

     <Reference Include="AntiXSSLibrary">
         <HintPath>..\..\..\..\Program Files (x86)\Microsoft Information Security\AntiXSS Library v4.2\NET40\AntiXSSLibrary.dll</HintPath>
     </Reference>

    which is surely not a desirable route and is going to break the solution when some one tries to work on the same project with a different file system structure in their system.  The optimal route would be to have this assembly from GAC so that the reference would be like

        

     <Reference Include="MicrosoftAntiXSS, Version=x.y.z.w, Culture=neutral, PublicKeyToken=pkt, processorArchitecture=MSIL" />

    Is there a way we can refer this assembly from GAC? 

    Monday, August 27, 2012 8:53 PM

All replies

  • I don't like the GAC, I rarely see a need for it. Is there a reason you do not want to place the dll in your binary folder (copy local)?

    http://pauliom.wordpress.com

    Tuesday, August 28, 2012 9:36 AM
  • I don't like the GAC, I rarely see a need for it. Is there a reason you do not want to place the dll in your binary folder (copy local)?

    http://pauliom.wordpress.com

    Yes. Our build policy prohibits binary files into source control. However we can have the same assembly installed in GAC, subject to satisfactory licenses. That way my application would seamlessly work without (f)ailing builds for any one who takes latest from the source control.
    Tuesday, August 28, 2012 12:37 PM
  • I think requiring all 3rd party DLLs to be in the GAC is an extremely limiting approach. Do you only ever use the "built-in" DLLs or ones that you write?


    http://pauliom.wordpress.com

    Tuesday, August 28, 2012 1:16 PM
  • How would you then accomodate for builds and multi-developer approach. It would be a total anarchy right?
    Tuesday, August 28, 2012 3:51 PM
  • Not really, I think the majority of "software shops" need to takle this issue. Partly why people are so enthusastic about technologies such as NuGet. I don't like having DLLs in source control but I do bow to having a single 'Referenced DLLs' folder. If not in source control then in a portal, shared disk, drop box(!), etc. I believe it is the MS TFS ALM patterns & practices recommendation to host dlls in TFS. You should take a look at their papers on branching, even if you you use another source control, the strategies are good to know as they cover the questions regarding getting references from builds et al.


    http://pauliom.wordpress.com

    Tuesday, August 28, 2012 4:04 PM