We Keep Coding

Unable to cast HttpRequestMessage.Properties["MS_RequestContext"] as OwinHttpRequestContext at build time but valid at runtime

I'm trying to manually fiddle with a property of my MS_RequestContext during Controller Activation inside my WebApi's CompositionRoot.
My Create method receives a System.Net.Http.HttpRequestMessage argument.
I can drill down request to grab
request.Properties["MS_RequestContext"]
Properties is a dictionary<string,object> That object will be an OwinHttpRequestContext at runtime.
But whenever I attempt to cast, so that I can access the properties on the RequestContext, I get a nasty-gram from Visual Studio
(request.Properties["MS_RequestContext"] as OwinHttpRequestContext).Request.Properties;
The error that comes back is:
The type or namespace 'OwinHttpRequestContext' could not be found (are you missing a using directive or an assembly reference?)
OwinHttpRequestContext lives inside the System.Web.Http.Owin namespace. My references are all set up. I even have added a using statement for good measure.
So the crazy part is that if I roll back my code that attempts to directly reference request.Properties, but instead set a breakpoint inside my Create method, I can -through a watch- execute
(request.Properties["MS_RequestContext"] as System.Web.Http.Owin.OwinHttpRequestContext).Request.Properties
without issue. I can confirm that I have no problem modifying the properties at runtime through the immediate window.
(request.Properties["MS_RequestContext"] as System.Web.Http.Owin.OwinHttpRequestContext).Request.Properties.Add("Foo","Bar")
And the property "Foo" will be available to all of my MessageHandlers.
Why am I not able to perform this same cast at build time?

OwinHttpRequestContext is not a public class. That is why you can't use it in code, but debugger can still see it.

Why can't I use the following IEnumerable<string>?

I'm getting the following error:
Error 25 The type or namespace name 'IEnumerable' could not be found (are you missing a using directive or an assembly reference?) C:\Development\Leverage\Leverage\Reports\SurveyLevel.aspx.cs 39 17 Leverage
because of this line:
private IEnumerable<string> GetDateParameters()
How do I deal with this? I tried to add in the line:
using System.IDisposable
at the top, but this doesn't fix it.

As others have said, you're missing using System.Collections.Generic;.
But that's giving you a fish; we should be teaching you to catch your own fish.
The way to solve this problem on your own is:
Enter the name of the type into your favourite search engine, and see what comes back:
IEnumerable(T) Interface (System.Collections.Generic)
http://msdn.microsoft.com/en-us/library/9eekhta0
Exposes the enumerator, which supports a simple iteration over a collection of a specified type.
See the bit that I highlighted in bold there? That's the namespace that you're missing.
If you still get the error then you are likely missing a reference; you can find out which DLL you have failed to reference by clicking on the link and reading the documentation page; it will tell you which DLL to reference.

You are missing a using System.Collections.Generic; statement at the top of the code file.
The generic IEnumerable<T> type cannot be found directly.
You could declare the full name instead:
private System.Collections.Generic.IEnumerable<string> GetDateParameters()

IEnumerable is in System.Collections
IEnumerable<T> is in System.Collections.Generic

You just need to add System.Collections.Generic namespace top of your code.
IEnumerable<T> belongs on this namespace in mscorlib.dll assembly.
You can use it like;
private System.Collections.Generic.IEnumerable<string> GetDateParameters()

Above answers are good. In my case, even after following the above answers it did not resolve the issue. Still the red squiggly constantly appeared.
Issue was the Framework of the project. It was by default set to .NET Framework 4.0.3 and changing to .NET Framework 4.0.0 will also help.
Save your Project properties after the change, build and it should all work.
Hope this helps.

Resolving an ambiguous reference

I'm trying to create a manager class to use with my charting tool, the problem is the tool I use, uses the same names for both a 3d and 2d charts which is resulting in ambiguous reference when I try to add the 2d library.. any ideas how best to resolve this?
For example,
using tool.2dChartLib;
using tool.3dChartLib;
BorderStyle is a member of both of these
I've tried casting the areas where I use BorderStyle. I suppose it could work if i just reference tool but then that would mean I'd have hundreds of tool.class lines instead of class

If the types with the same name exist in both namespaces, you have a couple of options:
1) If the number of types is small, create an alias for that type:
using BorderStyle3d = tool.3dChartLib.BorderStyle;
2) If the number of types is large, you can create an alias for the namespace:
using t3d = tool.3dChartLib;
Then in your code...
t3d.BorderStyle

You can use full type names, or create aliases:
using 2dBorderStyle = tool.2dChartLib.BorderStyle;

Use namespace alias
using twoDimensionLib = tool.2dChartLib;
using threeDimensionLib tool.3dChartLib;

I had similar problem that the class had ambiguous reference for the SAME namespace, so I deleted a specific Project (under Dependencies/{my.prj.name}.API) which had duplicated reference.
After that I referenced Project back with using of CTRL+.
Hope it'll work for you.
New reference of specific class

Lambda expression create unrelated compile error

Whenever I add a lambda expression (in the following form) to my wpf project, I get an error. The errors are nothing to do with the expression, but they arrive every time I add one.
here is my latest:
using ( LeisureServiceClient client = ServiceFactory.Instance.GetLeisureService() )
{
client.Execute( ServiceFactory.Instance.ConnectionDetails, new MoveBasketItemsToAccountCommand()
{
BasketItemIDs = bisList.ToList().ConvertAll<Guid>( bis => bis.ID )
} );
}
This seems perfectly valid to me, this gives the following compile error, highlighting client from client.Execute(...).
Error 43: The type 'System.Windows.DependencyObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
this code is nothing to do with a DependancyObject. Regardless, System.Windows is referenced in the .cs file, which also contains:
public class PointOfSaleViewModel : DependencyObject
which is quite happy to compile when the lambda expression is removed.
now, to add confusion... this is fine:
ServiceFactory.Instance.ShiftDataRefreshedEvent += ( s, e ) =>
{
Account = new ObservableCollection<BasketItemSummary>( ServiceFactory.Instance.CurrentContact.Account );
Basket = new ObservableCollection<BasketItemSummary>( ServiceFactory.Instance.Shift.OpenCurrentContact.Basket );
};
so, it's not the lambda expression itself that's causing the error, I'm out of ideas as to why this isn't compiling, and pretty keen to get some input before my head explodes.
Update
the alternate syntax suggested by a colleague
BasketItemIDs = bisList.ToList().ConvertAll( delegate( BasketItemSummary basketItem ) { return basketItem.ID; } )
also fails, giving the same compilation error.

It sounds to me like BasketItemSummary (or one of the properties) exposes this dependency on the public API - perhaps it is a base-class for the type. Simply: add the missing reference as it instructs.

I know this question is old, but in case someone else faces this problem:
Recently, I faced a problem much like yours. The solution I'm working includes a web project which has reference to a wpf project (for generating documents for downloading). After some modifications in the wpf project, the web project would not compile anymore, with the following error message:
Error 4 The type 'System.Windows.DependencyObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
After some debugging, I figured out the error message only pointed to lines which involved LINQ operations (first I also thought it was related to lambdas, as you).
In the end, the root of the problem were some wpf's visual tree helper methods I had taken from http://www.scottlogic.co.uk/blog/colin/2010/03/linq-to-visual-tree/. I had taken the methods from LinqToVisualTree and put them under the "System.Linq" namespace. Seemingly that was somehow conflicting with the original Linq extension methods in my web project, and once I changed the namespace of the LinqToVisualTree methods to something else the problem went away.

You need to add a reference to the dll in your project: right click on project, choose add reference.

Alias and namespace conflict in Visual Studio Designer

I have a namespace conflict between two referenced assemblies:
i.e., I'm referencing Foo.A.Foo and Foo.Bar, so when I say I want Foo.Bar.Control, VS is trying to find Foo.A.Foo.Bar.Control
I can twiddle the Designer.cs code by adding new global:Foo.Bar.Control(), but as soon as I change anything, VS switches back.
I know there's something about adding aliases directly to the reference, I've tried but haven't managed to find the right combination (inline alias, using alias, reference alias).
Help?

"extern alias" may be what you mean, but I'm not sure what the designer will do with it, unfortunately...
I'm not even sure that's what you're after though - that's normally for two types from different assemblies with the same name.
You can write namespace aliases with a using directive, e.g.
using FooControl = Foo.Bar.Control;
but again, the designer is going to rewrite your code...

OK, this isn't the answer, but it's what I found for a workaround:
namespace FooBar
{
class FooBarControlHack : Foo.Bar.Control { }
}
So I can do the following in the Designer.cs :
this.fooBarControl = new FooBar.FoorBarControlHack();