I started to read the NuGet docs to figure out what a NuGet package actually is.

NuGet package

A NuGet package is a file that makes it easy to add, remove, and update libraries and tools in Visual Studio projects that use the .NET Framework. A NuGet package is comprised by these three things:

• tools – The tools folder of a package is for powershell scripts and programs accessible from the Package Manager Console. After the folder is copied to the target project, it is added to the `$env:Path (PATH) environment variable.
• lib – Assemblies (.dll files) in the lib folder are added as assembly references when the package is installed.
• content – Files in the content folder are copied to the root of your application when the package is installed.

The documentation also indicate that NuGet was not designed for a project like Umbraco with so many files and such a complex web.config file. But I wanted to try and see how and if it was actually possible.

The strategy

The Umbraco project consists of libraries/assemblies and content, so it should be rather easy to create the NuGet package.

The first step was to download Umbraco 4.7.1 and go through the required assemblies and web.config. Initially I located assemblies that could already be found on NuGet and added these dependencies to the NuGet package. It later showed, that there would be versioning problems which I was not able to fix.

So instead of using dependencies to other NuGet packages as NuGet was actually intended, I  just added all the assemblies released with Umbraco 4.7.1.

Assemblies

The assemblies that gave me the most trouble was ClientDependency and ICharpCode.SharpZipLib.

ClientDependency was actually already in the NuGet feed, but the configuration transformation made from that NuGet package combined with the web.config transformation from the Umbraco package, yilded an invalid web.config file.  ClientDependency was therefor provided as an assembly directly from the Umbraco package and not as an external dependency.

The assembly ICSharpCode.SharpZipLib was also found in the NuGet feed, but Umbraco 4.7.1 required a specific version (0.85.5.452) that NuGet could not provide, and this assembly was as such also added as a part of the Umbraco package.

Web.config

The web.config configuration file for Umbraco is long and rather complex, and that makes merging of multiple web.config files difficult. The configuration transformation features in NuGet are limited, so you should expect problems when adding the Umbraco package to an existing website. The best results I achieved was when the package was added to an empty website or web application.

But even though a web.config file is almost empty, you should still prepare for some clean up.

Content

The Umbraco 4.7.1 binary release containes more than 1500 files. NuGet was not designed for this number of files and does not handle it very well. A complete package installation can take up to 5-10 min. depending on you machine and SSD/HDD configuration.

Example

The following describes the steps I used to run the Umbraco NuGet package against a web application project and the problems that arose.

1. Open Visual Studio 2010 and create an empty C# web application project

2. Open the NuGet Package Manager Console

3. Write:

Install-Package "Umbraco" -Source "c:\[NuGetPackageFolder]"

NuGetPackageFolder: Replace with the path to the folder containing the Umbraco.4.7.1.nupkg file. Important do not give the full path to the file, just the folder

4. Hit [ENTER] and wait for NuGet to do its work

5. Wait for the following two messages:

Successfully installed 'Umbraco 4.7.1'.
Successfully added 'Umbraco 4.7.1' to WebApplication1.

6. Compile and receive an error from web.config. (Multiple System.Web -> Compilation sections are present)

7. Remove the first and compile and run again

<compilation debug="true" targetFramework="4.0" />

8. At this point everything worked and I was able to follow the usual Umbraco installation steps

Conclusion

Umbraco is a fantastic CMS and NuGet is very cool, but together is not a good idea.

My goal was to find a way for installing Umbraco to a web project via NuGet, and that is not impossible, but I would not recommend it. I find it a lot easier to simply download the Umbraco released ZIP, and then extract and drag all files to my web application project. So that is what I will do

But if you still wants the Umbraco NuGet file, you can download it here.

Well this article explains it very well:
http://msdn.microsoft.com/en-us/magazine/cc164128.aspx

If you don’t want to read all, you find the best solution in the bottom of the article.

But you can also find the code here, download this library C# Threadpool.

AsyncRequest

class AsyncRequest
{
  private AsyncRequestState _asyncRequestState;

  public AsyncRequest(AsyncRequestState ars)
  {
    _asyncRequestState = ars;
  }

  public void ProcessRequest()
  {
    // This is where the non-cpu-bound activity would take place, such as
    // accessing a Web Service, polling a slow piece of hardware, or
    // performing a lengthy database operation. I put the thread to sleep
    // for two seconds to simulate a lengthy operation.
    Thread.Sleep(2000);

    _asyncRequestState._ctx.Response.Output.Write(
            "AsyncThread, {0}",
            AppDomain.GetCurrentThreadId());

    // tell asp.net I am finished processing this request
    _asyncRequestState.CompleteRequest();
  }
}

AsyncHandler

namespace EssentialAspDotNet.HttpPipeline
{
  // AsyncRequestState and AsyncRequest remain the same
  // as in the previous example

  public class AsyncHandler : IHttpAsyncHandler
  {
    static DevelopMentor.ThreadPool _threadPool;

    static AsyncHandler()
    {
      _threadPool =
        new DevelopMentor.ThreadPool(2, 25, "AsyncPool");
      _threadPool.PropogateCallContext = true;
      _threadPool.PropogateThreadPrincipal = true;
      _threadPool.PropogateHttpContext = true;
      _threadPool.Start();
    }

    public void ProcessRequest(HttpContext ctx)
    {
     // not used
    }

    public bool IsReusable
    {
      get { return false;}
    }

    public IAsyncResult BeginProcessRequest(HttpContext ctx,
                     AsyncCallback cb, object obj)
    {
      AsyncRequestState reqState =
                     new AsyncRequestState(ctx, cb, obj);
      _threadPool.PostRequest(
                     new DevelopMentor.WorkRequestDelegate(ProcessRequest),
                     reqState);

      return reqState;
    }

    public void EndProcessRequest(IAsyncResult ar)
    {
    }

    void ProcessRequest(object state, DateTime requestTime)
    {
      AsyncRequestState reqState = state as AsyncRequestState;

      // Take some time to do it
      Thread.Sleep(2000);

      reqState._ctx.Response.Output.Write(
                   "AsyncThreadPool, {0}",
                    AppDomain.GetCurrentThreadId);

      // tell asp.net you are finished processing this request
      reqState.CompleteRequest();
    }

  }
}

AsyncPage

namespace EssentialAspDotNet.HttpPipeline
{
 public class AsyncPage : Page, IHttpAsyncHandler
  {
    static protected DevelopMentor.ThreadPool _threadPool;

    static AsyncPage()
    {
      _threadPool =
       new DevelopMentor.ThreadPool(2, 25, "AsyncPool");
      _threadPool.PropogateCallContext = true;
      _threadPool.PropogateThreadPrincipal = true;
      _threadPool.PropogateHttpContext = true;
      _threadPool.Start();
    }

    public new void ProcessRequest(HttpContext ctx)
    {
      // not used
    }

    public new bool IsReusable
    {
      get { return false;}
    }

    public IAsyncResult BeginProcessRequest(HttpContext ctx,
                                            AsyncCallback cb, object obj)
    {
      AsyncRequestState reqState =
             new AsyncRequestState(ctx, cb, obj);
      _threadPool.PostRequest(
             new DevelopMentor.WorkRequestDelegate(ProcessRequest),
             reqState);

      return reqState;
    }

    public void EndProcessRequest(IAsyncResult ar)
    {
    }

    void ProcessRequest(object state, DateTime requestTime)
    {
      AsyncRequestState reqState = state as AsyncRequestState;

      // Synchronously call base class Page.ProcessRequest
      // as you are now on a thread pool thread.
      base.ProcessRequest(reqState._ctx);

      // Once complete, call CompleteRequest to finish
      reqState.CompleteRequest();
    }
  }
}

http://gerardmcgarry.com/blog/creating-a-google-sitemap-aspnet-website

http://www.codeproject.com/KB/aspnet/GoogleSiteMapProvider.aspx

http://www.resourceblender.com/

Reference:
http://west-wind.com/weblog/posts/132081.aspx

It is a tough task and the learning curve is quite steep.

You have to get to know the WinDbg. You can start here: http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx

Tess Ferrandez has some very nice “Debugging labs”, well take a look at: http://blogs.msdn.com/tess/

If you have a problem with a memory leak, take a look at his one:

http://blogs.msdn.com/tess/archive/2005/11/25/496899.aspx

Here is a new sample website with source code, it now disposes the page object and allows for WebControl rendering.

Dynamically Loading ASP.NET User Controls with jQuery v2.zip (25.52 kb)

—————————————— 

This post is only relevant if you are using WebForms. If you have converted to the MVC approach, then go read about Dependency Injection or NHibernate

If however you are using WebForms or are maintaining an application that was build with WebForms. Here is a way to partially render a usercontrol via jQuery (ajax).

Introduction

User controls are a great way to group markup and functionality, but in these AJAX times, the problem and nature of User Controls, in relation to ajax, is their fixed position in the Page Control tree.

Sam Mueller describes the issues and gives his solution to dynamically loaded user controls using jQuery.

Read it here:

http://samuelmueller.com/post/2008/12/20/Dynamically-Loading-ASPNET-User-Controls-with-jQuery.aspx

Sam Muellers raises some very interesting points, however I have two things I would like to change (URL and security).

URL

I very much like that Sam Mueller has found a solution to “directly” call a user control (view) with an URL. What I do not like is the URL to be called:

/ajax.svc/renderuc?path=/usercontrols/myusercontrol.ascx

I would like to be able to call the user control directly by this kind of URL:

/usercontrols/myusercontrol.ascx

And by using a HttpHandler this is possible. I have written an example here:

   1: public class AjaxUserControlHandler : IHttpHandler

   2:     {

   3:         public void ProcessRequest(HttpContext context)

   4:         {

   5:             // Get the path to the user control

   6:             string path = context.Request.Url.LocalPath;

   7: 

   8:             // Intialize the pseudo page and user control

   9:             Page page = new Page();

  10:             UserControl viewControl = page.LoadControl(path) as UserControl;

  11: 

  12:             // Display error if the user control was not found

  13:             if (viewControl == null)

  14:             {

  15:                 context.Response.StatusCode = 404;

  16:                 context.Response.Output.WriteLine("The requested url was not found");

  17:                 return;

  18:             }

  19: 

  20:             // Check existense of the AjaxEnabled attribute. Only add the AjaxEnabled attribut to 

  21:             // user controls that is safe for direct calls

  22:             var type = viewControl.GetType();

  23:             var attributes = type.GetCustomAttributes(typeof (AjaxEnabledAttribute), true);

  24:             AjaxEnabledAttribute attribute = attributes.FirstOrDefault() as AjaxEnabledAttribute;

  25: 

  26:             // If the attribute was not found, display an error

  27:             if (attribute == null)

  28:             {

  29:                 context.Response.StatusCode = 403;

  30:                 context.Response.Output.WriteLine("Access to the resource is not allowed");

  31:                 return;

  32:             }

  33: 

  34:

  35:             // Check if the request is valiud with regards to the requirements of the attribute.

  36:             // If not, display error

  37:             if ((attribute.Method == RequestMethodSupport.GET && context.Request.RequestType != "GET")

  38:                 || (attribute.Method == RequestMethodSupport.POST && context.Request.RequestType != "POST"))

  39:             {

  40:                 context.Response.StatusCode = 403;

  41:                 context.Response.Output.WriteLine(string.Format("The request method {0} is not allowed.", context.Request.RequestType));

  42:                 return;

  43:             }

  44: 

  45:             // Add user control to the pages control tree

  46:             page.Controls.Add(viewControl);

  47: 

  48:             // Disable caching, remove this if you will allow client caching

  49:             context.Response.CacheControl = "No-Cache";

  50: 

  51:             // Execute and return result to Output stream

  52:             context.Server.Execute(page, context.Response.Output, true);

  53:         }

  54: 

  55:         public bool IsReusable

  56:         {

  57:             get { return true; }

  58:         }

  59:     }

To make it work, you need to add the following to httpHandlers tag in the web.config.

<add verb="*" path="*.ascx" type="[NAMESPACE].AjaxUserControlHandler, [ASSEMBLY]"/>

Security

I have implemented an AjaxEnabled attribut, so that it is not possible to directly call any of the user controls (if you know the path to them) in the solution.

The attribute is simple and looks like this:

   1: public class AjaxEnabledAttribute : Attribute

   2: {

   3:     [DefaultValue(RequestMethodSupport.All)]

   4:     public RequestMethodSupport Method { get; set; }

   5: }

   6: 

   7: public enum RequestMethodSupport

   8: {

   9:     All,

  10:     GET,

  11:     POST

  12: }

By doing this, the handler will only allow calls to user controls that have the [AjaxEnabled[ attribute, like this:

   1: [AjaxEnabled]

   2: public partial class Test : System.Web.UI.UserControl

   3: {

   4:     ...

Conclusion

With the HttpHandler, and the attribute in place, my two concerns (url and security) are dealt with.

You are now able to call a user control directly:

/usercontrols/myusercontrol.ascx

And you are only able to call user controls that have the AjaxEnabled attribute.

Any comments and suggestions are welcome btw

http://www.invoke.co.nz/products/docx.aspx

————————————————————————————–

We have decided to release another component we've been using (FREE of charge, click here to download).
This library creates Word Documents (.docx) using .NET. It is written
purely in C#, you don't need any Word viewing applications or Interop
(COM) dlls installed/registered.

It works very similar to a
Repeater control, instead of HTML markup you create a docx template
using Word 2007 (Open XML format), specify parameters/placeholders to
hold values then pass the document to the library, it will then merge
those fields.

Here's an example:
To create a Word (.docx document)
- Open up Word 2007, create a new file and type in the following (without the " "):
"Hello %NAME%"
- Save & Exit (save as hello.docx)

- Create a new VS 2008 Console Application project, add a reference to the docx library, copy paste the code into Program.cs

static void Main(string[] args)

{

    File.Copy("hello.docx", "hello_ready.docx", true); // create a copy of template file for later use
    // DocumentDataSource holds name/value pair data

    DocumentDataSource source = new DocumentDataSource();

    source["NAME"] = "Joe Bloggs"; // assign a value to parameter %NAME%

    DocumentRenderer.ProcessDocument("hello_ready.docx", source); // process the document

    Process.Start("hello_ready.docx"); // run MS Word to see merged document

}

Result

That's an over simplified example, the library is able to do a lot more, if you'd like to download it or find out more please click here,

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

——————————–

Cross-site scripting (XSS) is widely regarded as the number one security issue on the web. But since XSS gets all the limelight, few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work. Scary!

How CSRF works

So, what’s it all about? All web application platforms are potentially vulnerable to CSRF, but in this post I’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:

   1:  public class UserProfileController : Controller

   2:  {

   3:      public ViewResult Edit() { return View(); }

   4:  

   5:      public ViewResult SubmitUpdate()

   6:      {

   7:          // Get the user's existing profile data (implementation omitted)

   8:          ProfileData profile = GetLoggedInUserProfile();

   9:  

  10:          // Update the user object

  11:          profile.EmailAddress = Request.Form["email"];

  12:          profile.FavoriteHobby = Request.Form["hobby"];

  13:          SaveUserProfile(profile);

  14:  

  15:          TempData["message"] = "Your profile was updated.";

  16:          return View();

  17:      }

  18:  }

This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…

Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:

   1:  <body onload="document.getElementById('fm1').submit()">

   2:      <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">

   3:          <input name="email" value="hacker@somewhere.evil" />

   4:          <input name="hobby" value="Defacing websites" />

   5:      </form>

   6:  </body>

Next, they somehow persuade a victim to visit this page (basic social engineering, look it up). When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.

Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.

Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.

Ways to stop CSRF

There are two main ways to block CSRF:

• Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
• Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.

Using the AntiForgeryToken helpers

With Preview 5, Microsoft has added a set of helpers to the “futures” assembly, Microsoft.Web.Mvc.dll, that give you a means to detect and block CSRF using the “user-specific tokens” technique.

To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,

   1:  <% using(Html.Form("UserProfile", "SubmitUpdate")) { %>

   2:      <%= Html.AntiForgeryToken() %>

   3:      <!-- rest of form goes here -->

   4:  <% } %>

This will output something like the following:

   1:  <form action="/UserProfile/SubmitUpdate" method="post">

   2:      <input name="__MVC_AntiForgeryToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />

   3:      <!-- rest of form goes here -->

   4:  </form>

At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __MVC_AntiForgeryToken, with the same value as the random hidden value shown above.

Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,

   1:  [ValidateAntiForgeryToken]

   2:  public ViewResult SubmitUpdate()

   3:  {

   4:      // ... etc

   5:  }

This is an authorization filter that checks that:

• The incoming request has a cookie called __MVC_AntiForgeryToken
• The incoming request has a Request.Form entry called __MVC_AntiForgeryToken
• These cookie and Request.Form values match

Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.

This prevents CSRF because even if a potential victim has an __MVC_AntiForgeryToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent.

Using salt

Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,

   1:  <%= Html.AntiForgeryToken("someArbitraryString") %>

… and also in [ValidateAntiForgeryToken], e.g.,

   1:  [ValidateAntiForgeryToken(Salt="someArbitraryString")]

   2:  public ViewResult SubmitUpdate()

   3:  {

   4:      // ... etc

   5:  }

Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required. (If anyone can suggest other use cases for salt, please let me know.)

Limitations of the Anti-Forgery helpers

ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:

• All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
• It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
• It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
• It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.

In conclusion, ASP.NET MVC’s anti-CSRF helpers are easy to use, and work very nicely thank you!

Read more about it here:

http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx

Or take a qucik look directly on these following link:

Microsoft recently released a cool new ASP.NET server control – <asp:chart /> – that can be used for free with ASP.NET 3.5 to enable rich browser-based charting scenarios:

• Download the free Microsoft Chart Controls
• Download the VS 2008 Tool Support for the Chart Controls
• Download the Microsoft Chart Controls Samples
• Download the Microsoft Chart Controls Documentation
• Visit the Microsoft Chart Control Forum