Keep in mind that this doesn’t give you the current minute (or whatever) rather it gives you the closest minute (or whatever).

using System;

namespace MikeInMadison
{
    public static class Extensions
    {
        public static DateTime Round(this DateTime d, RoundTo rt)
        {
            DateTime dtRounded = new DateTime();

            switch (rt)
            {
                case RoundTo.Second:
                    dtRounded = new DateTime(d.Year, d.Month, d.Day, d.Hour, d.Minute, d.Second);
                    if (d.Millisecond >= 500) dtRounded = dtRounded.AddSeconds(1);
                    break;
                case RoundTo.Minute:
                    dtRounded = new DateTime(d.Year, d.Month, d.Day, d.Hour, d.Minute, 0);
                    if (d.Second >= 30) dtRounded = dtRounded.AddMinutes(1);
                    break;
                case RoundTo.Hour:
                    dtRounded = new DateTime(d.Year, d.Month, d.Day, d.Hour, 0, 0);
                    if (d.Minute >= 30) dtRounded = dtRounded.AddHours(1);
                    break;
                case RoundTo.Day:
                    dtRounded = new DateTime(d.Year, d.Month, d.Day, 0, 0, 0);
                    if (d.Hour >= 12) dtRounded = dtRounded.AddDays(1);
                    break;
            }

            return dtRounded;
        }

        public enum RoundTo
        {
            Second, Minute, Hour, Day
        }
    }
}

            var rates = from ri in RateItems
                        group ri by ri.Time.Round(Extensions.RoundTo.Hour) into g
                        select new
                        {
                            Time = g.First().Time.Round(Extensions.RoundTo.Hour),
                            High = g.Max(g2 => g2.Bid),
                            Low = g.Min(g2 => g2.Bid),
                            Open = g.First().Bid,
                            Close = g.Last().Bid
                        };

Because of the way ASP.NET works, creating a code library that is easy to update and that can be used by multiple team members working on multiple distinct projects is challenging. You may want your code library to incorporate binary dll files from vendors or the open source community, web user controls (.ascx files), classes containing useful functions that are written in different languages, style sheets, web pages, images, etc.. The trick with ASP.NET is that often times certain types of files must go in specific places. For instance, dll files need to be placed in the bin directory, while your custom classes and server controls need to be placed in the App_Code directory. Web pages, web user controls, style sheets, and images can generally be placed in any directory.

svn:externals

The best solution that I have come up with this far is to use the “externals” function build into Subversion. To get up-to-speed on Subversion and the best way to use it from Visual Studio, read my previous posts here and here.

The Subversion externals property allows you to include a file or directory from one repository in another repository. For instance, Directory#1 in RepositoryA can be included in RepositoryB without RepositoryB actually containing or keeping track of Directory#1. This is done in such a way that the working copies of RepositoryB will contain Directory#1, but Subversion knows that Directory#1 is actually in RepositoryA instead of RepositoryB. This is all somewhat confusing when we are starting out, so lets walk through actually creating everything.

Creating the shared library

Since it we can’t really create web user controls in class library projects, the code library that we are going to share is actually going to be a web site project. That way we can include everything that gets used in web sites. Set up a web site with something like the following structure:

As you can see, the web site I’ve created doesn’t actually contain any web pages (.aspx files). I have only web user controls (.ascx files), dll files, and C# code files. I have items in folders in the App_Code folder, the Bin folder, and the root folder. I should note that this web site will not currently build – that is because Database.cs depends on the EntitySpaces libraries, which are not in the root of the Bin folder. We’ll get to the reason for this in a minute. The directories named “Shared” are the ones that are going to get copied into each web site that we want to use this library with, so place everything you want to use more than once in the appropriate “Shared” directory. You might want this solution and this solution only to contain unit tests (for instance) for the library, so you may want to place those outside of the “Shared” directories.

So now that the shared web site is set up, we need to get it into a Subversion repository. Follow the directions here, from my previous post. We need to get the project into a repository so that we can use the svn:externals function in the web sites we want to include these files in.

Using the shared library

Now that we have our web site library in a repository and ready to go, we’ll need another web site that we actually want to use the shared library in. If you’ve been following my posts, you probably know the drill by now. Create a new web site following these directions and put it in a repository.

To review, these are the steps we have done so far:

• Created a web site containing the files we want to go in our shared library (we’ll call it BShared)
• Placed BShared in a repository (it got its own repository)
• Created a web site that will use our shared web site (we’ll call it BTest)
• Placed BTest in a repository (it also got its own repository)

Next comes the easy part: linking the files from the BShared repository into the BTest repository. To do this, right click on “Solution ‘BTest’ (1 project)” in the Visual Studio Solution Explorer, and select “Properties…” from the VisualSVN menu.

From the Properties window that opens, click “Add…”. For the property name select “svn:externals”. In the “Property value:” section, enter something that looks like the following, matched to your repository:

The settings above will place:

1. BShared/Shared into BTest/SharedLibrary,
2. BShared/App_Code/Shared into BTest/App_Code/SharedLibrary, and
3. BShared/Bin/Shared into BTest/Bin/SharedLibrary.

Note that the list above is abbreviated – the full paths are actually used, just like in the screenshot. Save the properties, and then run an Update from the VisualSVN menu. You should notice that the “Shared” directories get checked out of the BShared repository and placed in the corresponding SharedLibrary folders. After all of these steps, the web site I’m working on looks like this:

There is one problem that still needs to be taken care of. You need to select all of the files in Bin/SharedLibrary, and copy them directly into Bin. This has to be done because class libraries cannot be in subdirectories of Bin – they have to be in the Bin root. Make sure you copy and past them to Bin instead of moving them! Moving them would remove them from your shared library project.

Summary

So that is all you really need to do to get a shared library up and running. You can do the above steps for multiple projects on multiple computers using the same shared library, but there are some important things you should consider. When you Commit your solution from the VisualSVN menu, the external files will not be committed (assuming they are in separate repositories, like the way I set them up). To commit the external files and therefor make changes to the shared library, you have to right click on the “SharedLibrary” folder you want to commit and from there use “Commit…”. You’ll have to do this for each SharedLibrary folder that has changes to commit.

In my opinion the ability to update the shared library from any project that is using it is one of the most useful features of setting up a shared library this way. We don’t have to open up a new project, write code, test it, copy it over, and then finally use it – instead we can simply act as if the library is actually a part of the project we are working on. For instance, if we were to add a web user control in SharedLibrary/BCMS/Controls and then commit SharedLibrary, the new web user control would be seen by all of the projects using this shared library when they run an update on the solution!

A few extra notes:

• Remember that when using this method any change to the shared web site project is seen by all of the projects using it. This means that a file getting deleted in one project gets deleted in all projects. A solution to this is to use revision numbers in your svn:externals value. Example:

  Web/SharedLibrary -r5 file:///\seeker/TeamRepository/BShared/trunk/Web/Shared
  Web/App_Code/SharedLibrary -r5 file:///\seeker/TeamRepository/BShared/trunk/Web/App_Code/Shared
  Web/Bin/SharedLibrary -r5 file:///\seeker/TeamRepository/BShared/trunk/Web/Bin/Shared

• When initially developing code to incorporate into the library, I suggest you do it outside of the SharedLibrary folders. That way you don’t have to worry about buggy code breaking others web sites. When you have it working, copy it over into the appropriate SharedLibrary folder and run a Commit on it. An alternative is to simply not run a Commit until you are sure the code is good.
• For more information about svn:externals go here.
• This method will work perfectly in a team environment. The svn:externals property only needs to be set up once. After it is set up and the solution is committed once, other team members who check out the solution or update their working copies will automatically get the externals.

VisualSVN is simply a front-end for the command line Subversion functions, just like TortoiseSVN. The difference between the two is that TortoiseSVN is a “add-in” for Windows and VisualSVN is an add-in for Visual Studio. However, VisualSVN uses TortoiseSVN for its functions, so really VisualSVN is just another way to use TortoiseSVN. To explain: TortoiseSVN allows you to access Subversion functions from Windows with a nice GUI, and VisualSVN allows you to access TortoiseSVN from within Visual Studio.

There are a few other Subversion add-ins for Visual Studio out there, the most popular probably being AnkhSVN. AnkhSVN is great, but in my experience it’s a little more complicated that what most people need.

Installation

To get started we’ll first need to download VisualSVN. A 30-day full-featured trial is available, and if you participate in an open-source project you can get a license for free! Even if you don’t qualify for the free license, I would highly suggest checking out this great piece of software – once you get used to it you’ll love it.

I’ll brush over the actual installation, but note that if you have multiple versions of Visual Studio installed, VisualSVN will work with them all (except for the free Visual Studio Express Editions). Just a quick review before we get into the details – the following programs are needed for everything to work:

• Visual Studio
• TortoiseSVN
• Subversion (came with TortoiseSVN)
• VisualSVN

After you install VisualSVN and open Visual Studio, you’ll notice the VisualSVN menu. This menu will soon become one of your best friends, but first you’ll might have to fight with it a bit. To minimize this fighting, I’ll explain how to set up a new VisualSVN-enabled web site.

A VisualSVN Enabled Web Site

You’ll have to set up your directories a little differently than you are used to if you want to use VisualSVN with a web site project. To begin, you need to create an empty Visual Studio solution. Usually web sites don’t need or use solution files, but to make the “Get Solution from Subversion…” function to work nicely we’ll need a solution file to get.

Select “File >> New Project…” in VS, and find the “Blank Solution” project type. This will create a solution that we can later add projects to. For this example I’ll name my solution “SVNWebSite”. I’m going to use C:\TeamProjects, which already contains a few solutions in subfolders. Before you hit OK, make sure the “Create directory for solution” checkbox is checked.

Now we have an empty solution with a solution file located at C:\TeamProjects\SVNWebSite\SVNWebSite.sln. Next we need a web site, but it needs be located in a sub-directory of C:\TeamProjects\SVNWebSite\. This has to be the case to make VisualSVN work nicely. You’ll find some other hacks around this issue, but from what I’ve seen a sub-directory is the easiest.

Right-click in the Solution Explorer and select “Add >> New Web Site…”. I’ll place the site in a directory called “Web”, the full path being C:\TeamProjects\SVNWebSite\Web, with “File System” selected for the location.

Now we have a solution containing a web site, but nothing is yet in a Subversion repository. Note that we even haven’t used Subversion, TortoiseSVN, or VisualSVN yet! Well, now is the time. To import your solution into a Subversion repository, select “Add Solution to Subversion…” from the VisualSVN menu. I’m going to select “Add to a New Repository” and place it at C:\My Repositories\SVNWebSite. You can leave the “Working copy root folder:” setting alone.

Our repository has been created and the working copy directory has been set, but we have one more step to complete before the files are actually added to the repository. Select “Commit…” from the VisualSVN menu, enter a comment, and press OK.

Now our files are finally in a repository! You can now to a commit at any time to take a snapshot of your solution. You can treat this just like any other solution – opening, closing, adding files, etc. all work the same.

A few extra notes:

• You can now work on a web site as a team. Once the previous steps have been done, anyone with access to the repository you created can simply use “Get Solution from Subversion…” from the VisualSVN menu. This will get a “working copy” of the solution so it can be developed locally. Once a team member makes a change, they do a Commit and the other team members run an Update, both of which can be accessed from the VisualSVN menu. This way each developer has their own local version of the site, but it stays up to date with other developers changes when Update is run.
• You can delete the solution and project directory (but don’t delete the repository!) from your projects directory to archive old projects. To work on them again, simply use “Get Solution from Subversion…” from the VisualSVN menu.
• You can have multiple versions of the same site. To do this, create a branch using the “Branch…” function and put it in a location like file:///C:/My Repositories/SVNWebSite/branches/, which was created automatically for you. You can then use “Get Solution from Subversion…” to check out the branch, or the trunk, or check them both out and place them in different locations.
• You can still administer the repository using TortoiseSVN from the Windows shell.

Subversion can be used from either the command line or from a GUI. Most users don’t need to used the more advanced features and should use a GUI. I suggest TortoiseSVN, the most popular Subversion interface for Windows. Subversion comes with TortoiseSVN, so all we need to install is TortoiseSVN.

Start by grabbing the latest version and installing it. I use the default installation settings. You may need to restart after installation.

Now that Subversion and TortoiseSVN are installed we can create a new repository. This will be the location that the Subversion database, which will contain the version information for our files, will be stored. I suggest somewhere that is secure and that you are sure you won’t accidentally delete. I’m going to use C:\SVNRepository. If you plan to have multiple people using your repository, use a location on a network share.

So now we’ve created the SVNRepository directory and are ready to actually create the repository. Make sure the directory is empty. While navigated to the folder, right click and select “TortoiseSVN >> Create Repository Here…”.

You’ll be asked to select the type of repository you want to create – “Native filesystem (FSFS)” or “Berkeley database (BDB)”. I always choose FSFS, but you can use BDB if you wish. If you are creating the repository on a network share, you MUST choose FSFS, for magical reasons.

After you select the repository type you should get a message saying that the repository was successfully created. You’ll now see a few folders and directories in the repository folder you selected. Don’t mess with them unless you know what you are doing. I don’t know what I’m doing, so I don’t mess with them.

Your repository is currently empty, so you’ll need to find some files to put in it. I’ll just use a singe blank text file for now, but you can use anything you wish. In my case, this would usually be a directory containing a Visual Studio project or a web site. Navigate to the folder you want to import, right click, and select “TortoiseSVN >> Import…”.

We’ll have to point Subversion to the repository we created earlier, and we can add an optional note.

After you click “OK”, you should see a log of what was done. This screen tells us that “Some File.txt” was successfully added to the repository, and it is at revision 1.

This part is confusing. Now that the folder is in the repository it can be checked out so that you can edit it. Whenever you edit the files you should be editing them in a “Working copy” of the repository. Although we have imported our folder into the repository, we don’t yet have a working copy! I’m going to create a new directory called “My Working Copy”, and then use “SVN Checkout…” from the right-click menu.

One again navigate to your repository, and click OK. You should get a screen showing a log of the checkout, but I’m not displaying it here.

The “My Working Copy” directory now contains “Some File.txt” along with a hidden folder called “_svn”. The “_svn” folder keeps track of the working copy, so make sure you don’t delete or edit it. Once you are sure your files were checked out properly, you can go ahead and delete the originals. (Note: You should probably back them up first, in case the repository gets corrupted.)

We are almost there. Let’s open up the “Some File.txt” in your working copy and add a line of text to it. I added the line “This is a new line of text.” and then saved the file. I’ve also added a new file called “New File.txt” to m working copy directory.

Lets say that we’ve made a few changes to our file and now want to commit our changes to the repository. Committing our changes will make a point-in-time backup and it will also allow others using the repository with their own working copies to stay up to date by running the “SVN Update” function after we do a commit.

I’ve clicked “SVN Commit” from the right-click menu, and now I can add another comment. In this screenshot I’ve also right-clicked on “New File.txt” and clicked “Add” to that Subversion starts keeping track of the file. You should do the same after deleting files by right clicking on them in the commit window and clicking Delete. Only the files that are checked will be committed. After we click OK, we’ll once again get a log of what was done.

That should be enough to get you going with Subversion!

A few extra notes:

• You can check out as many working copies as you like. Put each one its own directory and run “SVN Update” before editing each copy. This will make sure that the copy you are editing is up-to-date. Also, run “SVN Commit” after you are done editing each copy to make sure that your other working copies will get the most current version when you update them.
• If you need to get a non-working copy, say to upload a web site to a production server without all of the “_svn” files use “TortoiseSVN >> Export…”. This will place a clean up-to-date revision of your repository in the folder you choose.