Steve Smith's Blog

ASP.NET MVC 2 and Windows Azure

ssmith — Wed, 17 Mar 2010 14:05:13 GMT

If you upgrade an Azure web instance to use ASP.NET MVC 2, make sure you mark the System.Web.Mvc reference as Copy Local = true. Otherwise, your deployment will fail. And you won’t get any good feedback from Windows Azure as to the cause of the problem. So you’ll start searching the web for help, and perhaps you’ll stumble on this post, and you’ll realize that you didn’t set Copy Local = true on your System.Web.Mvc assembly reference in your ASP.NET MVC 2 web instance. And you’ll leave happy (or at least slightly happier) than when you came.

That is all.

Simple Branching and Merging with SVN

ssmith — Tue, 16 Mar 2010 16:49:51 GMT

It’s a good idea not to do too much work without checking something into source control. By “too much work” I mean typically on the order of a couple of hours at most, and certainly it’s a good practice to check in anything you have before you leave the office for the day. But what if your changes break the build (on the build server – you do have a build server don’t you?) or would cause problems for others on your team if they get the latest code? The solution with Subversion is branching and merging (incidentally, if you’re using Microsoft Visual Studio Team System, you can shelve your changes and share shelvesets with others, which accomplishes many of the same things as branching and merging, but is a bit simpler to do).

Getting Started

I’m going to assume you have Subversion installed along with the nearly ubiquitous client, TortoiseSVN. See my previous post on installing SVN server if you want to get it set up real quick (you can put it on your workstation/laptop just to learn how it works easily enough).

Overview

When you know you are going to be working on something that you won’t be able to check in quickly, it’s a good idea to start a branch. It’s also perfectly fine to create the branch after-the-fact (have you ever started something thinking it would be an hour and 4 hours later realized you were nowhere near done?). In any event, the first thing you need to do is create a branch. A branch is simply a copy of the current trunk (a typical subversion setup has root directories called trunk, tags, and branches – it’s a good idea to keep this and to put your branches in the branches folder). Once you have a new branch, you need to switch your working copy so that it is bound to your branch. As you work, you may want to merge in changes that are happening in the trunk to your branch, and ultimately when you are done you’ll want to merge your branch back into the trunk. When done, you can delete your branch (or not, but it may add clutter). To sum up:

Create a new branch
Switch your local working copy to the new branch
Develop in the branch (commit changes, etc.)
Merge changes from trunk into your branch
Merge changes from branch into trunk
Delete the branch

Create a new branch

From the root of your repository, right-click and select TortoiseSVN –> Branch/tag… as shown at right (click to enlarge). This will bring up the Copy (Branch / Tag) interface. By default the From WC at URL: should be pointing at the trunk of your repository. I recommend (after ensuring that you have the latest version) that you choose to make the copy from the HEAD revision in the repository (the first radio button). In the To URL: textbox, you should change the URL from /trunk to /branches/NAME_OF_BRANCH. You can name the branch anything you like, but it’s often useful to give it your name (if it’s just for your use) or some useful information (such as a datestamp or a bug/issue ID from that it relates to, or perhaps just the name of the feature you are adding.

When you’re done with that, enter in a log message for your new branch. If you want to immediately switch your local working copy to the new branch/tag, check the box at the bottom of the dialog (Switch working copy to new branch/tag). You can see an example at right.

Assuming everything works, you should very quickly see a window telling you the Copy finished, like the one shown below:

Switch Local Working Copy to New Branch

If you followed the instructions above and checked the box when you created your branch, you don’t need to do this step. However, if you have a branch that already exists and you would like to switch over to working on it, you can do so by using the Switch command. You’ll find it in the explorer context menu under TortoiseSVN –> Switch:

This brings up a dialog that shows you your current binding, and lets you enter in a new URL to switch to:

In the screenshot above, you can see that I’m currently bound to a branch, and so I could switch back to the trunk or to another branch. If you’re not sure what to enter here, you can click the […] next to the URL textbox to explore your repository and find the appropriate root URL to use. Also, the dropdown will show you URLs that might be a good fit (such as the trunk of the current repository).

Develop in the Branch

Once you have created a branch and switched your working copy to use it, you can make changes and Commit them as usual. Your commits are now going into the branch, so they won’t impact other users or the build server that are working off of the trunk (or their own branches). In theory you can keep on doing this forever, but practically it’s a good idea to periodically merge the trunk into your branch, and/or keep your branches short-lived and merge them back into the trunk before they get too far out of sync.

Merge Changes from Trunk into your Branch

Once you have been working in a branch for a little while, change to the trunk will have occurred that you’ll want to merge into your branch. It’s much safer and easier to integrate changes in small increments than to wait for weeks or months and then try to merge in two very different codebases. To perform the merge, simply go to the root of your branch working copy and right click, select TortoiseSVN->Merge. You’ll be presented with this dialog:

In this case you want to leave the default setting, Merge a range of revisions. Click Next. Now choose the URL to merge from. You should select the trunk of your current repository (which should be in the dropdownlist, or you can click the […] to browse your repository for the correct URL). You can leave everything else blank since you want to merge everything:

Click Next. Again you can leave the default settings. If you want to do something more granular than everything in the trunk, you can select a different Merge depth, to include merging just one item in the tree. You can also perform a Test merge to see what changes will take place before you click Merge (which is often a good idea). Here’s what the dialog should look like before you click Merge:

After clicking Merge (or Test merge) you should see a confirmation like this (it will say Test Only in the title if you click Test merge):

Now you should build your solution, run all of your tests, and verify that your branch still works the way it should, given the updates that you’ve just integrated from the trunk. Once everything works, Commit your changes, and then continue with your work on the branch. Note that until you commit, nothing has actually changed in your branch on the server. Other team members who may also be working in this branch won’t be impacted, etc. The Merge is purely a client-side operation until you perform a Commit.

In a more real-world scenario, you may have conflicts. When you do, you’ll be presented with a dialog like this one:

It’s up to you which option you want to go with. The more frequently you Merge, the fewer of these you’ll have to deal with. Also, be very sure that you’re merging the right folders together. If you try and merge your trunk with some subfolder in your branch’s structure, you’ll end up with all kinds of conflicts and problems. Fortunately, they’re only on your working copy (unless you commit them!) but if you see something like that, be sure to doublecheck your URL and your local file location.

Merge Your Branch Back Into Trunk

When you’re done working in your branch, it’s time to pull it back into the trunk. The first thing you should do is follow the previous step’s instructions for merging the latest from the trunk into your branch. This lets you ensure that what you have in your branch works correctly with the current trunk. Once you’ve done that and committed your changes to your branch, you’re ready to proceed with this step.

Once you’re confident your branch is good to go, you should go to its root folder and select TortoiseSVN->Merge (as above) from the explorer right-click menu. This time, select Reintegrate a branch as shown below:

Click Next.

You’ll want it to merge with the trunk, which should be the default:

Click Next.

Leave the default settings:

Click Test merge to see a test, and then if all looks good, click Merge. Note that if you haven’t checked in your working copy changes, you’ll see something like this:

If on the other hand things are successful:

After this step, it’s likely you are finished working in your branch. Don’t forget to use the ToroiseSVN->Switch command to change your working copy back to the trunk.

Delete the Branch

You don’t have to delete the branch, but over time your branches area of your repository will get cluttered, and in any event if they’re not actively being worked on the branches are just taking up space and adding to later confusion. Keeping your branches limited to things you’re actively working on is simply a good habit to get into, just like making sure your codebase itself remains tidy and not filled with old commented out bits of code.

To delete the branch after you’re finished with it, the simplest thing to do is choose TortoiseSVN->Repo Browser. From there, assuming you did this from your branch, it should already be highlighted. In any event, navigate to your branch in the treeview on the left, and then right-click and select Delete.

Enter a log message if you’d like:

Click OK, and it’s gone. Don’t be too afraid of this, though. You can still get to the files by viewing the log for branches, and selecting a previous revision (anything before the delete action):

If for some reason you needed something that was previously in this branch, you could easily get back to any changeset you checked in, so you should have absolutely no fear when it comes to deleting branches you’re done with.

Resources

If you’re using Eclipse, there’s a nice write-up of the steps required by Zach Cox that I found helpful here.

Fix: SqlDeploy Task Fails with NullReferenceException at ExtractPassword

ssmith — Wed, 10 Mar 2010 16:11:01 GMT

Still working on getting a TeamCity build working (see my last post). Latest exception is:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets(120, 5): error MSB4018: The "SqlDeployTask" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Data.Schema.Common.ConnectionStringPersistence.ExtractPassword(String partialConnection, String dbProvider)
at Microsoft.Data.Schema.Common.ConnectionStringPersistence.RetrieveFullConnection(String partialConnection, String provider, Boolean presentUI, String password)
at Microsoft.Data.Schema.Sql.Build.SqlDeployment.ConfigureConnectionString(String connectionString, String databaseName)
at Microsoft.Data.Schema.Sql.Build.SqlDeployment.OnBuildConnectionString(String partialConnectionString, String databaseName)
at Microsoft.Data.Schema.Build.Deployment.FinishInitialize(String targetConnectionString)
at Microsoft.Data.Schema.Build.Deployment.Initialize(FileInfo sourceDbSchemaFile, ErrorManager errors, String targetConnectionString)
at Microsoft.Data.Schema.Build.DeploymentConstructor.ConstructServiceImplementation()
at Microsoft.Data.Schema.Extensibility.ServiceConstructor`1.ConstructService()
at Microsoft.Data.Schema.Tasks.DBDeployTask.Execute()
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult)

This time searching yielded some good stuff, including this thread that talks about how to resolve this via permissions. The short answer is that the account that your build server runs under needs to have the necessary permissions in SQL Server. You’ll need to create a Login and then ensure at least the minimum rights are configured as described here:

Required Permissions in Database Edition

Alternately, you can just make your buildserver account an admin on the database (which is probably running on the same machine anyway) and at that point it should be able to do whatever it needs to.

If you’re certain the account has the necessary permissions, but you’re still getting the error, the problem may be that the account has never logged into the build server. In this case, there won’t be any entry in the HKCU hive in the registry, which the system is checking for permissions (see this thread). The solution in this case is quite simple: log into the machine (once is enough) with the build server account. Then, open Visual Studio (thanks Brendan for the answer in this thread).

Summary

Make sure the build service account has the necessary database permissions
Make sure the account has logged into the server so it has the necessary registry hive info
Make sure the account has run Visual Studio at least once so its settings are established

In my case I went through all 3 of these steps before I resolved the problem.

Could Not Load Type Microsoft.Build.Framework.BuildEventContext

ssmith — Wed, 10 Mar 2010 14:50:07 GMT

Setting up a TeamCity build and got this error:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets(80, 5): error MSB4018: The "SqlSetupDeployTask" task failed unexpectedly.
System.TypeLoadException: Could not load type 'Microsoft.Build.Framework.BuildEventContext' from assembly 'Microsoft.Build.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at Microsoft.Build.BuildEngine.TaskExecutionModule.SetBatchRequestSize()
at Microsoft.Build.BuildEngine.TaskExecutionModule..ctor(EngineCallback engineCallback, TaskExecutionModuleMode moduleMode, Boolean profileExecution)
at Microsoft.Build.BuildEngine.NodeManager..ctor(Int32 cpuCount, Boolean childMode, Engine parentEngine)
at Microsoft.Build.BuildEngine.Engine..ctor(Int32 numberOfCpus, Boolean isChildNode, Int32 parentNodeId, String localNodeProviderParameters, BuildPropertyGroup globalProperties, ToolsetDefinitionLocations locations)
at Microsoft.Build.BuildEngine.Engine.get_GlobalEngine()
at Microsoft.Data.Schema.Build.DeploymentProjectBuilder.CreateDeploymentProject()
at Microsoft.Data.Schema.Tasks.DBSetupDeployTask.BuildDeploymentProject(ErrorManager errors, ExtensionManager em)
at Microsoft.Data.Schema.Tasks.DBSetupDeployTask.Execute()
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)

The usual searching didn’t bring back anything useful, but I figured out that I’d missed a dropdownlist in the TeamCity project setup:

Originally I was using Microsoft .NET Framework 2.0 for my MSBuild task. Changing it to 3.5 (as shown above) got me past this error (and on to the next one…).

Fix: Can’t Change or Remove Visual Studio 2008 from DVD

ssmith — Mon, 08 Mar 2010 18:51:18 GMT

If you installed Visual Studio 2008 on a 64-bit operating system, you may have trouble when you try ad add or remove functionality by inserting the disk (or remounting the ISO image). I believe this is because of the path used to install the 32-bit Visual Studio program. When you run the setup.exe off of the disk, you get this:

Clicking on Change or Remove Visual Studio 2008 brings up this dialog:

But not long after it appears, it disappears to be replaced with:

Microsoft Visual Studio 2008 Setup

A problem has been encountered while loading the setup components. Canceling setup.

FIX: Use Add or Remove Programs

Launch the Add or Remove Programs dialog in Windows, and find Microsoft Visual Studio Team System 2008 Team Suite – ENU (or whichever SKU you installed). Click Uninstall/Change. From here you should be able to change your installed components of Visual Studio successfully:

Thanks to Brendan for the tip!

If you’re still having trouble, or encounter additional problems like “a selected drive is no longer valid. please review your installation path settings” then check out Heath Stewart’s posts:

Adding features to Visual Studio 2008 may fail to load setup components

Do Not Repair VS 2008 SP1 from Installation Media

Open Visual Studio Files As Administrator

ssmith — Wed, 03 Mar 2010 16:42:16 GMT

Working with IIS as your web server, or working with Azure projects, are two examples of situations in which Visual Studio (2008+) needs to be running as Administrator (on Windows Vista or Windows 7). If you don’t run it as such, you may be faced with a dialog like this one (for Azure):

Now of course if you have Visual Studio pinned to your taskbar or start menu, you can launch it as admin by right-clicking and selecting Run As Administrator, as Jeff Blankenburg shows here. That’s great for one-off things, but in my scenario I really want to be able to double-click on a .sln file and have it open with Visual Studio as an administrator:

The solution as suggested by http://twitter.com/JeremySkinner is to go and update VSLauncher.exe so that it always runs as administrator. You’ll find VSLauncher here:

C:\Program Files (x86)\Common Files\microsoft shared\MSEnv

Right click on it, select Properties, and then the Compatibility tab. From here you can check the box for Run this program as an administrator:

With that done, you can now go right into your project structure in Windows Explorer and open whichever solution or project files you want, and they will open in an Administrator privileged instance of Visual Studio, with the elevated privileges Azure and IIS require.

Eliminate Repetition with Action

ssmith — Tue, 02 Mar 2010 21:41:45 GMT

Yesterday I was looking at some old code and refactoring it to clean it up (in this case I wasn’t the original author, but I’ve written code just like this). The application in question was a simple process that had to run once per month, on demand, and so was coded up as an EXE application. As it ran, it provided updates on its progress, so it looked something like this:

static void Main(string[] args)

    Console.WriteLine("Starting Application @ " + DateTime.Now);

    var parser = new ParameterParser();

    Parameters parameters = parser.Parse(args);

    Console.WriteLine("Finalizing Revenue for " + parameters.DateRange.StartDate.Month + "/" + parameters.DateRange.StartDate.Year);

    IRevenueRepository repository = new LinqRevenueRepository();

    var mostRecentFinalizedDate = repository.GetMostRecentFinalizedDate();

    if (mostRecentFinalizedDate >= parameters.DateRange.StartDate)

        throw new Exception("Revenue already finalized for period.");

    Console.WriteLine("Begin FinalizePublisherRevenue @ " + DateTime.Now);

    repository.FinalizePublisherRevenue(parameters.DateRange);

    Console.WriteLine("End FinalizePublisherRevenue @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin FinalizeAccountManagerRevenue @ " + DateTime.Now);

    repository.FinalizeAccountManagerRevenue(parameters.DateRange);

    Console.WriteLine("End FinalizeAccountManagerRevenue @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin FinalizeAgencyRevenue @ " + DateTime.Now);

    repository.FinalizeAgencyRevenue(parameters.DateRange);

    Console.WriteLine("End FinalizeAgencyRevenue @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin FinalizeAccountManagerRevenueDetail @ " + DateTime.Now);

    repository.FinalizeAccountManagerRevenueDetail(parameters.DateRange);

    Console.WriteLine("End FinalizeAccountManagerRevenueDetail @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin FinalizeAgencyRevenueDetail @ " + DateTime.Now);

    repository.FinalizeAgencyRevenueDetail(parameters.DateRange);

    Console.WriteLine("End FinalizeAgencyRevenueDetail @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin SaveAccountManagerRevenueSummary @ " + DateTime.Now);

    repository.SaveAccountManagerRevenueSummary(parameters.DateRange);

    Console.WriteLine("End SaveAccountManagerRevenueSummary @ " + DateTime.Now);

    Console.WriteLine();

    Console.WriteLine("Begin SavePublisherRevenueSummary @ " + DateTime.Now);

    repository.SavePublisherRevenueSummary(parameters.DateRange);

    Console.WriteLine("End SavePublisherRevenueSummary @ " + DateTime.Now);

In reviewing this simple application, I noticed a few areas where it could benefit from obvious improvement that wouldn’t take long at all to implement. I refactored the core logic into a separate service class, which took in an ILogger rather than writing directly to the console and also created a custom exception to take care of the case where the program was being re-run for a period that had already been finalized. But the significant improvement came in the area of logging the start/end of each method call, which I did by using an Action<T> method. You can see in the original code there was a lot of repetition – every method call requires 3 lines that are virtually identical except for the name of the method being called. Clearly a violation of Don’t Repeat Yourself. I replaced each 3-line call with a single line method call that took in an Action<DateRange> parameter representing the method to invoke. The result is that all of the magic strings for the method names disappeared, and the code is much more compact and easily understood:

public void FinalizeMonth(DateRange dateRange)

    DateTime mostRecentFinalizedDate = _revenueRepository.GetMostRecentFinalizedDate();

    if (mostRecentFinalizedDate >= dateRange.StartDate)

        throw new RevenuePreviouslyFinalizedException("Revenue already finalized for period: " + dateRange);

    ExecuteStep(dateRange, _revenueRepository.FinalizePublisherRevenue);

    ExecuteStep(dateRange, _revenueRepository.FinalizeAccountManagerRevenue);

    ExecuteStep(dateRange, _revenueRepository.FinalizeAgencyRevenue);

    ExecuteStep(dateRange,

                _revenueRepository.FinalizeAccountManagerRevenueDetail);

    ExecuteStep(dateRange, _revenueRepository.FinalizeAgencyRevenueDetail);

    ExecuteStep(dateRange,

                _revenueRepository.SaveAccountManagerRevenueSummary);

    ExecuteStep(dateRange, _revenueRepository.SavePublisherRevenueSummary);

private void ExecuteStep(DateRange dateRange, Action<DateRange> stepMethod)

    _logger.Info("Begin " + stepMethod.Method.Name + " @ " + DateTime.Now);

    stepMethod.Invoke(dateRange);

    _logger.Info("End " + stepMethod.Method.Name + " @ " + DateTime.Now);

Note that within ExecuteStep(), I’m able to extract the name of the method being called by referring to the Action<T>.Method.Name property. This is something I wasn’t previously aware of, but it helped clean up my code significantly in this case (the FinalizeMonth method is now only about 10 lines of code, instead of the original main() method which was over 30 lines of code. The new version is also testable, and in fact I added unit tests to confirm everything works as expected, since these also were lacking from the original code. The result, after about an hour, is something much cleaner that I or another developer will be able to maintain witha greatly reduced learning curve and risk of breakage.

SQLite Error IDbCommand and IDbConnection implementation in the assembly System.Data.SQLite could not be found.

ssmith — Fri, 26 Feb 2010 22:35:04 GMT

I just ran into a problem with SQLite and NHibernate, which was giving me this error message:

The IDbCommand and IDbConnection implementation in the assembly System.Data.SQLite could not be found.

The strange thing was, it worked fine from within Visual Studio, but it died when I used my ClickToBuild.bat file, which calls msbuild and runs my tests from the command line. A bit of searching led me to a similar problem on StackOverflow, which produced the answer:

Use the x64 binaries.

I downloaded the latest version of SQLite (SQLite-1.0.65.0-binaries.zip) and made sure to use the .dll in the x64 folder, and the problem disappeared. It’s worth noting that I’m running on Windows 7 x64. I’m assuming that since Visual Studio 2008 is still in the dark ages and only runs as a 32-bit application, that’s the reason why this issue only appeared outside of Visual Studio.

Untrusted Projects and Blocked Files in Visual Studio

ssmith — Thu, 25 Feb 2010 17:01:52 GMT

I was just trying to open a project I was emailed as a zip file from a colleague. VS2010 opens up saying:

You should only open projects from a trustworthy source. The project file 'project' may have come from a location that isn’t fully trusted. It could represent a security risk by executing customer build steps when opened in Microsoft Visual Studio that could cause damage to your computer or compromise your private information.

Which is fine… but in this case I know the project is OK so I click the box and tell it to get on with it. Next, I try to run the project, but I am faced with this:

Error    1    The "ValidateXaml" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Users\Steve\Downloads\SomeFile.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///C:\Users\Steve\Downloads\SomeFile.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at Microsoft.Silverlight.Build.Tasks.ValidateXaml.XamlValidator.Execute(ITask task)
   at Microsoft.Silverlight.Build.Tasks.ValidateXaml.XamlValidator.Execute(ITask task)
   at Microsoft.Silverlight.Build.Tasks.ValidateXaml.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)

Naturally I go to the URL it references which talks about loadFromRemoteSources but in my case this is no help, and in any event is a red herring that hides the real issue.

Windows Wants Me To Be Safe

…even if it means I can’t do my work. It turns out that Visual Studio’s warning wasn’t enough to protect me, but Windows was blocking many of the files I needed for this project to run. There are a few ways you can fix this – if you’ve already unzipped the project and there are only a couple of such DLLs, you can open each one in Windows Explorer, select Properties, and then click the Unblock button as shown below:

Note that if you Unblock the zip file first, then everything you unzip out of it will also be unblocked, so this is the way to go. Another option, if you have a FAT/FAT32/exFAT file system drive handy (say, a USB Flash Drive), is to simply copy the files to and then from such a drive (it will lose any knowledge of having been blocked, etc. in the transfer).

There’s a good write-up with some additional information on Scott Frolich’s post to the Falafel blog about Windows Blocked Files, too.

SELECT from a Stored Procedure

ssmith — Wed, 24 Feb 2010 16:45:31 GMT

Occasionally I find myself wanting to SELECT from a SPROC in SQL Server. Usually this is because I want to ORDER the results or filter them further with a WHERE clause. Unfortunately, you can’t just do this:

SELECT *
FROM
(EXEC mySproc foo, bar)

There are several workarounds here, and the appropriate one depends mostly on whether you have any control over the use of the stored procedure, or how it works. For example, you could choose to use a VIEW instead of a stored procedure. Unfortunately, a VIEW usually won’t work if you need to pass parameters to your stored procedure (which I’m guessing you are). If your sproc is literally just a wrapper for a query that has no dependencies on parameters, then yeah, you probably should just use a view, and then of course you can select from it to your heart’s content.

INSERT-EXEC

The simplest approach that doesn’t require making any changes to your perfectly good stored procedure is to declare a temporary table with the appropriate schema to match what the sproc outputs. Then INSERT the stored procedure’s results into the temp table and SELECT from it. An example looks like this:

CREATE TABLE #Result
(
  ID int,  Name varchar(500), Revenue money
)
INSERT #Result EXEC RevenueByAdvertiser '1/1/10', '2/1/10'
SELECT * FROM #Result ORDER BY Name
DROP TABLE #Result

This is the approach I favor when I simply need to apply a WHERE or an ORDER BY to an existing stored procedure. There are actually quite a few other ways to share data between stored procedures or between ad hoc queries and stored procedures. Erland Sommerskog has a nice article outline How to Share Data Between Stored Procedures that you might want to read for more options.

Erland also notes a few limitations to the above approach, which you should keep in mind. I only use this approach for quick ad hoc queries, not for use in production code, because of the limitations involved.