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.

The web server is located here:
C:\Program Files (x86)\Common Files\microsoft shared\DevServer\9.0\WebDev.WebServer.EXE

Arguments

Example

C:\Program Files (x86)\Common Files\microsoft shared\DevServer\9.0>
WebDev.WebServer.EXE /port:8080 /path:"C:\Users\Administrator\Documents\Visual Studio 2008\Projects\WebApplication\Compiled" \vpath:"\"

http://blogs.msdn.com/nativeconcurrency/archive/2009/01/12/an-introduction-to-native-concurrency-in-visual-studio-2010.aspx

My Visual Studio 2008 opened the solution file with no problem. However, when I was to add a new class, user control, aspx file or similar, I received the error:

Could not find part of "c:\Program Files\Microsoft Visual Studio 9.0\…\ItemTemplatesCache…"

[and the path to the ItemTemplatesCache in Visual Studio 2008 folder].

The solution

Well, one slution would be to reinstall or repair installation of Visual studio 2008. However, after searching for a while I found a solution that is much easier:

1. Open "Visual Studio 2008 Command Prompt" as an Administrator
2. Run the command: "devenv /installvstemplates"
3. That's it

It takes a while but it completely rebuild your item template cache if it is corrupt or completely missing like me.

—

In this video we learn how to use Visual Studio 2005 to debug ASP.NET AJAX applications. We are shown how the ScriptManager is used to access the JavaScript created by the ASP.NET AJAX server controls, and we also see how to use the Sys.Debug class to insert a trace message and a breakpoint.

View video: WinVideo-ASP-DebugAJAXApplicationsUsingVisualStudio2005.wmv (16.89 mb)

http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx

Or here:

http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx

Original post here: http://webproject.scottgu.com/csharp/migration2/migration2.aspx

—

Step 1: Create a New VS 2005 Web Application Project

The best strategy to migrate an existing VS 2005 Web Site Project is to first create a new blank VS 2005 Web Application Project in a separate directory. This avoids changing any of the existing web site files, and will allow us to copy in already implemented functionality. You can add this new project either to your existing solution (ideal when you have lots of other class library projects that you want to use), or by starting a new instance of Visual Studio and creating a new solution+project within it.

To create a new VS 2005 Web Application Project in a new solution, choose File->New Project and then select the ASP.NET Web Application Project option. If you want to add a VS 2005 Web Application Project to an existing solution right click on the solution node and select Add->New Project. Name the project whatever you want, and select the language type you want to use.

Once you’ve either created or added this new VS 2005 Web Application Project, delete the "default.aspx" and "web.config" that are added to it by default (since you’ll instead just want to copy in your existing ones). In this example I added the new Web Application Project to my existing solution. If you do this you’ll then be left with a blank project that looks like this:

Step 2: Setup Project References

Before migrating any code into your new VS 2005 Web Application Project, you should first make sure to setup any project or assembly references for it. You can see the list of default references with new VS 2005 Web Application Projects under the References node above. You can right-click on the References node to add new References to the project, as well as setup project-to-project references if you have other class library projects part of the solution.

Once you have all of your references setup for the project, right click on the project and choose "Build" (or just hit Ctrl-Shift-B). This will build the project and verify that any project to project references are working.

Step 3: Copy the files from the Web Site Project into the new Web Application Project

The easiest way to add your existing files from a VS 2005 Web Site Project is simply select all the files in the Web Site Project copy and paste them into the New Web Application Project.

At this point none of the files have been converted and the directory structure looks the same as it did in the Web Site Project.

If the Data Source Configuration Wizard is launched during the copy, cancel the dialog and allow the rest of the files to be copied.

One difference between a VS 2005 Web Site Project and a VS 2005 Web Application Project is that the VS 2005 Web Site Project Model dynamically generates the tool-generated partial class half of a page, and does not persist it on disk. The VS 2005 Web Application Project model on the other-hand does save this partial class on disk within files that have a .designer.cs extension and compiles it using the in-memory VS compilers when a build occurs (one benefit of this is faster build times). You can learn more about how this code-generation model works by reading this tutorial.

Notice how the code-behind files for each page/user-control is still associated with the .aspx, .master and .ascx content. However, no .designer.cs files have been generated.

As part of our next step, we will be converting these pages to persist their partial class declarations on disk within a .designer.cs file.

Step 4: Converting the Project Files

To convert pages and classes within the project, right click the root node of the Web Application Project and select "Convert to Web Application". This will cause VS 2005 to recursively examine every page, user-control, and master-page in the project and automatically generate a .designer.cs file for each, as well as change the .aspx/.ascx files to use the "codebehind" rather than the "codefile" attribute. This command will also rename App_Code to Old_App_Code. When it’s completed your project will look as follows:

After you’ve added these files, build the project again to see if there are any compile errors. The most likely cause of errors at this stage are: a) You are missing an assembly reference, or b) You are using a dynamically generated type like the "Profile" object or a Typed DataSet. If you are missing an assembly reference, you should go to the reference manager and add it. If you are using a dynamically generated type, please see the Appendix of this tutorial for details on how to use it with the new VS 2005 Web Application Project option.

VERY, VERY IMPORTANT: Because ASP.NET 2.0 tries to dynamically compile any classes it finds under the /App_Code directory of an application at runtime, you explictly *DO NOT* want to store classes that you compile as part of your VS 2005 Web Application Project under an "app_code" folder. If you do this, then the class will get compiled twice — once as part of the VS 2005 Web Application Project assembly, and then again at runtime by ASP.NET. The result will most likely be a "could not load type" runtime exception — caused because you have duplicate type names in your application. Instead, you should store your class files in any other directory of your project other than one named "app_code". This will be handled automatically by the "Convert to Web Applicaiton" command. This command will rename the folder Old_App_Code.

Step 5: Running the Site

Once you have completed the above steps, you should be able to cleanly compile and run your application. By default it will use the built-in VS Web Server (aka Cassini) to run the site. You can alternatively configure the project to use IIS instead. To manage these settings, right-click on the project and pull up its project properties. You can then select the "Web" tab to configure these runtime settings:

Step 6: Optionally Adding Namespaces

By default, pages and classes built within the VS 2005 Web Site Project option are not automatically added using a code namespace. Pages/Controls/Classes built using the VS 2005 Web Application Project option, on the other hand, do — so new pages/classes you add will by default have namespaces.

You can easily add namespaces in code to existing classes within VS using the "Surround With" context menu command in the C# code editor. Simply select a class (or multiple classes) in the source editor, then right click and select "Surround With->Namespace" option:

Note that .aspx, .ascx, .master, .ashx, .asmx, and .asax files contain "inherits=" or "class=" attributes that list the class names they should invoke. So if you add namespaces to the code-behind files of these types you will also want/need to update the inherits and class declarations to also contain the namespace you use. For example: a Details.aspx page would need to have its page directive changed from "inherits=Details_aspx" to "inherits=WebApplication5.Details_aspx"

One easy way to bulk edit the namespace is to use Edit->Find and Replace command to find all inherits=" strings and change them to inherits="WebApplication. (note the trailing "." — which will be prepended before the previous class name).

Appendix 1: Migrating Declarative Typed DataSets (.xsd files)

If you have Strongly Typed DataSets under the App_Code directory in your VS 2005 Web Site Project, then you need to make an additional change to fixup the connection string in web.config.

Specifically, you need to open each DataSet in the Data Designer and select each TableAdapter and re-set the connectionstring for the object (you can do this by selecting the TableAdapter in the designer and then changing the "ConnectionString" property in the propertygrid).

Appendix 2: Migrating Code that works with the ASP.NET 2.0 Profile Object

ASP.NET 2.0 adds support for a new feature called "Profile Personalization". This enables developers to easily store and retrieve profile data about a user visiting the site within a personalization database. With VS 2005 Web Site Projects, ASP.NET automatically adds a strongly typed "Profile" object to each page in the project that provides a strongly-typed mapping of all properties defined within the "profile" section of the application’s web.config file. Developers can then get intellisense against this, and automatically save/retrieve values from it. For example, if an application’s web.config file had this section in it:

Then developers could write this code within their pages to save/retrieve "Teachers" information:

This is supported because with the VS 2005 Web Site Project option Visual Studio is dynamically creating and adding a "ProfileCommon" class named "Profile" into every code-behind instance.

Well here is the trick of how to do it. Download and install the following

- Download Explorer add-in for VS2005

or read more about here

http://www.csharper.net/blog/_explore_in_windows__add_in_for_visual_studio_2005.aspx