Quantcast
Channel: ASPNETWebStack Issue Tracker Rss Feed
Viewing all 7215 articles
Browse latest View live
↧

Closed Issue: Model validation fails on property of type System.Type [225]

June 5, 2013, 4:11 pm
$
0
0
The model binder that processes the request body validates the data using validator defined in 'BodyModelValidator'. The default implementation 'DefaultBodyModelValidator' recursively iterates the object graph. This iteration however fails to properly address the situation when it encounters a property of System.Type type (and potentially other similar types). It considers that type as a composite type recursively processing its sub-properties and fails to get the value of DeclaringMethod property, that throws an exception if accessed on any type that is not a generic argument.

(For search indexing purposes: the exception presents itself as InvalidOperationException with the message "Method may only be called on a Type for which Type.IsGenericParameter is true.")

Current implementation already tests for "simple" types via TypeHelper.IsSimpleType, however this function addresses only primitive types and string, DateTime, Decimal, Guid, DateTimeOffset and TimeSpan.

The quick fix would be to extend that list. However, a better approach would be to expose a mechanism to allow such an extension by a developer: delegate, attribute, virtual method?

For instance, it might be beneficial to skip deep instance inspection in case of types with custom serialization that are treated as opaque.
Comments: Verified. Works for Json media type formatter. Xml formatter throws errors when serializing Type instances though.
↧
Search

Closed Issue: Handle byte[]s better in the DefaultBodyModelValidator [891]

June 5, 2013, 4:27 pm
$
0
0
A customer has reported performance problems with the DefaultBodyModelValidator over large byte arrays (2 MB). We should handle this better.
Comments: Verified.
↧
↧

Closed Issue: Model-binding collection fails when non-collection property shares a prefix [832]

June 5, 2013, 4:39 pm
$
0
0
Given a collection property named "foos" and another property named "foosBar" on an object being model-bound, because of the implementation of the PrefixContainer (specifically the IsPrefixMatch method), if "foosBar" is on a boundary checked by Array.BinarySearch, the algorithm will miss all the collection properties, and the collection will be null after model-binding completes.

I've included failing test in pull request [4032](http://aspnetwebstack.codeplex.com/SourceControl/network/forks/bmsullivan/prefixcontainertests/contribution/4032). I'm honestly not sure how to fix this without breaking something else or significantly impacting model-binding performance.
Comments: Verified
↧

Commented Issue: ViewContext.Writer.Write() inside @helper writes directly to the view instead of the HelperResult [517]

June 5, 2013, 5:11 pm
$
0
0
I'm trying to get result of @helper method as variable without writing it to the view (I'm going to do it later after some transformations). And inside this helper I'm using extension to the HtmlHelper which should write some code to the output of the helper.

The simplest code would be like following:

@helper SomeHelper() {
<b>
Html.ViewContext.Writer.Write("Hello world!"); //NOTE: this code is inside of HtmlHelper extension function in the library at nuget.
</b>
}

And I want use this helper later on my page:

@SomeHelper()

And I will get following result:

Hello World
<b></b>

But hello world should be inside of <b> tag, but it is outside.

One possible solution is override Html.ViewContext.Writer.Write with helper's writer.

PS: original problem is described there: https://github.com/danludwig/BeginCollectionItem/issues/3
Comments: What is proposed solution to achieve this?
↧

Closed Issue: Error in web.config for areas added to Empty ASP.NET MVC 4 Application [406]

June 5, 2013, 5:23 pm
$
0
0
Starting out with an empty MVC 4 application, System.Web.Optimizations.dll is not referenced.

In the web.config in an area's views folder, line 18 adds the <add namespace="System.Web.Optimization"/> element pointing to an unreferenced assembly.

This causes a an error when trying to render any view in that area.


Comments: Thanks for reporting this issue. For MVC5 we are planning brand new scaffolding experience (Add Area is part of it). We will take this suggestion into consideration when handling scaffolding area (and other constructs) for an Empty project.
↧
↧

Commented Issue: Value validator should swallow exceptions from getters when traversing tree [611]

June 5, 2013, 5:23 pm
$
0
0
Otherwise the exception bubbles up and request fails
Comments: We should check that relative URIs are fixed when this is addressed.
↧

Closed Issue: BodyModelValidator fails on relative URIs [269]

June 5, 2013, 5:24 pm
$
0
0
The value validator should instead either record a model error for that property or ignore it, but not bubble it up.

Stack Trace:

Exception:
ExceptionType: System.InvalidOperationException
Message: This operation is not supported for a relative URI.
StackTrace:
at System.Uri.get_AbsolutePath()
at System.ComponentModel.ReflectPropertyDescriptor.GetValue(Object component)
at System.Web.Http.Metadata.Providers.AssociatedMetadataProvider.<>c__DisplayClass9.<GetPropertyValueAccessor>b__8()
at System.Web.Http.Metadata.ModelMetadata.get_Model()
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(ModelMetadata metadata, ValidationContext validationContext, Object container, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateProperties(ModelMetadata metadata, ValidationContext validationContext, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(ModelMetadata metadata, ValidationContext validationContext, Object container, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateProperties(ModelMetadata metadata, ValidationContext validationContext, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(ModelMetadata metadata, ValidationContext validationContext, Object container, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateElements(IEnumerable model, ValidationContext validationContext, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(ModelMetadata metadata, ValidationContext validationContext, Object container, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateProperties(ModelMetadata metadata, ValidationContext validationContext, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(ModelMetadata metadata, ValidationContext validationContext, Object container, String prefix)
at System.Web.Http.Validation.DefaultBodyModelValidator.Validate(Object model, Type type, ModelMetadataProvider metadataProvider, HttpActionContext actionContext, String keyPrefix)
at System.Web.Http.ModelBinding.FormatterParameterBinding.<>c__DisplayClass1.<ExecuteBindingAsync>b__0(Object model)
at System.Threading.Tasks.TaskHelpersExtensions.<>c__DisplayClass2b`1.<>c__DisplayClass2d.<Then>b__2a()
at System.Threading.Tasks.TaskHelpersExtensions.<>c__DisplayClass3d.<ToAsyncVoidTask>b__3c()
at System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)
Comments: Duplicate of https://aspnetwebstack.codeplex.com/workitem/611
↧

Edited Issue: Dictionary model binder throws exception when no values present [373]

June 6, 2013, 10:10 am
$
0
0
This was working fine in MVC 3, I'm not sure if this is an intended change or not.

In MVC4, the model binder cannot properly bind a Dictionary<> if the form was submitted with no values. Consider the following controller action:

[HttpPost]
public void Index(Dictionary<int, bool> values, FormCollection form)
{
}

In MVC3 if this action was called with no values, the dictionary would simply contain 0 entries. In MVC4 if this action is called with no values, it throws an exception: "Specified cast is not valid."

Changing the controller action to the following produces the expected result as it was in MVC3:

[HttpPost]
public void Index(FormCollection form)
{
var values = new Dictionary<int,bool>();
this.UpdateModel(values, "values");
}

I have attached a solution which demonstrates the problem.
↧
Search

Commented Issue: Dictionary model binder throws exception when no values present [373]

June 6, 2013, 10:10 am
$
0
0
This was working fine in MVC 3, I'm not sure if this is an intended change or not.

In MVC4, the model binder cannot properly bind a Dictionary<> if the form was submitted with no values. Consider the following controller action:

[HttpPost]
public void Index(Dictionary<int, bool> values, FormCollection form)
{
}

In MVC3 if this action was called with no values, the dictionary would simply contain 0 entries. In MVC4 if this action is called with no values, it throws an exception: "Specified cast is not valid."

Changing the controller action to the following produces the expected result as it was in MVC3:

[HttpPost]
public void Index(FormCollection form)
{
var values = new Dictionary<int,bool>();
this.UpdateModel(values, "values");
}

I have attached a solution which demonstrates the problem.
Comments: This was integrated into master with commit: 26d31700413459c319414f87f6146b197df49059
↧
↧

Edited Issue: Dictionary model binder throws exception when no values present [373]

June 6, 2013, 10:21 am
$
0
0
This was working fine in MVC 3, I'm not sure if this is an intended change or not.

In MVC4, the model binder cannot properly bind a Dictionary<> if the form was submitted with no values. Consider the following controller action:

[HttpPost]
public void Index(Dictionary<int, bool> values, FormCollection form)
{
}

In MVC3 if this action was called with no values, the dictionary would simply contain 0 entries. In MVC4 if this action is called with no values, it throws an exception: "Specified cast is not valid."

Changing the controller action to the following produces the expected result as it was in MVC3:

[HttpPost]
public void Index(FormCollection form)
{
var values = new Dictionary<int,bool>();
this.UpdateModel(values, "values");
}

I have attached a solution which demonstrates the problem.
↧

Closed Issue: WebSecurity.CreateUserAndAccount IDictionary casting [870]

June 6, 2013, 10:47 am
$
0
0
The WebSecurity.CreateUserAndAccount method checks for an input on the propertyValues parameter and converts it to a RouteValueDictionary before it is passed on to the ExtendedMembershipProvider.

When constructing a RouteValueDictionary using an object (typeof object), the result is unexpected ... item/indexing is lost. In this case, the new keys are "keys" and "values".

Casting the input to an IDictionary<string, object> fixes the issue.

Current:
```
IDictionary<string, object> values = null;
if (propertyValues != null)
{
values = new RouteValueDictionary(propertyValues);
}
```

Suggested:
```
values = new RouteValueDictionary((IDictionary<string, object>)propertyValues);
```

I'm not clear on why the propertyValues parameter is an object type and not IDictionary<string, object>. Either the type should be changed or type assignment checking should be performed.
Comments: verified.
↧

Closed Issue: Bug: serialisation-deserialisation loses UserAgent.Count [303]

June 6, 2013, 10:48 am
$
0
0
When I deserialise-serialise-deserialise and compare request and request2 in code below, UserAgent header has the correct .ToString() value but count is 0. So my unit test was failing:


var stream = new FileStream("Request.bin", FileMode.Open);
var serializer = new MessageContentHttpMessageSerializer();
var request = serializer.DeserializeToRequest(stream);

var memoryStream = new MemoryStream();
serializer.Serialize(request, memoryStream);

memoryStream.Position = 0;
var request2 = serializer.DeserializeToRequest(memoryStream);

Comments: Based on the comment, looks like this is fixed.
↧

Closed Feature: More virtual extensibility to XmlMediaTypeFormatter and make it instance-type-aware [189]

June 6, 2013, 11:12 am
$
0
0
I'm going to try and keep this brief - but it might be difficult.

In the project I'm writing at the moment, I've customised the XML formatter to correctly serialize an instance based on it's actual type rather than the method's return type - paralleling what the JSON.Net serialiser does; which fixes a bug with XML content for the following service:

interface IFoo{
string Bar { get; set; }
}

class Foo : IFoo {
public string Bar { get; set; }
}

public class ExampleController : ApiController
{
public IFoo GetExample(){
return new Foo() { Bar = "Hello World!" };
}
}

When executed as JSON content, you get a JSON representation of the Foo.

When executed as XML content, the operation fails because the DataContractSerializer expects Foo to be added as a known type.

This can be fixed by changing the return type of the method - however, in my current project this just isn't desirable; as it's a multi-tenant application where controllers can be overriden based on request hostname; and the actual return types of the underlying service operations only have to implement the interface - but could have many more members specific to their remote operation.

To fix this - I created an 'Ex' version of the formatter - that picks up some data added by an ActionFilter which is used by the programmer to state declaratively that XML serialization should consider the whole-object, not just the static return type. I attach that code.

You'll notice that I've had to use the GetPerRequestFormatterInstance for this purpose - which is not ideal. More on that in a moment.

This solution does not, nor can it, solve cases where an IEnumerable<IFoo> or IDictionary<string, IFoo> will be returned. Again, the JSON.Net serializer is quite happy with this scenario, whereas the XML one is not.

In this case, it would be necessary to customise the actual serializer instance that is constructed based on the instance of the enumerable being serialized - a simple dynamic implementation being to forward-scan an IEnumerable or IDictionary (although IDictionary can be treated as IEnumerable<KeyValuePair<TKey, TValue>>) looking for all instances whose actual types are different to the static type of the generic, and then adding those to a dynamic list of known types.

This cannot be done in the current codebase - the creation of the serializer is private. However, making it virtual won't help on it's own either, because the value to be serialized must also be passed.

Ideally we need to be able to override the serializer creation code - and have that receive not only the type to be constructed, but also the value AND a state value that can be built from the request's properties (perhaps the properties themselves, or even the request).

I know that the GetPerRequestFormatterInstance method goes some way to solving this - and that it is possible to override serializers through the SetSerializer method - but the former is a very inefficient solution where lots of types are involved - and the second is clumsy. They also do not allow us to handle the case of the enumerables, as I say.

I will look forward to any furhter thoughts on this. If I've missed something blindingly obvious, then do let me know!
Comments: Verified.
↧
↧

Closed Issue: XElement is not working with DefaultBodyModelValidator [800]

June 6, 2013, 11:28 am
$
0
0
The scenario broken is that if defining XElement property in odata entity type, POST or PUT the entity will result in failure. The error message is:

PUT http://localhost:83/911518e0-e801-48db-9eff-d513a6ca82f3/Resources(R1) HTTP/1.1
Host: localhost:83
Accept: application/json; odata=minimalmetadata
Content-Type: application/json; odata=minimalmetadata
Content-Length: 143

{
"Name":"R1",
"InstrinsicSettings":"<VMTier instances=\"3\">\r\n <MoreSettings />\r\n</VMTier>"
}

[From the trace log...]
Operation=JQueryMvcFormUrlEncodedFormatter.GetPerRequestFormatterInstance
WebApiTest.vshost.exe Information: 0 : Message='Value read='WebApiTest.Resource'', Operation=ODataMediaTypeFormatter.ReadFromStreamAsync
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
WebApiTest.vshost.exe Error: 0 : Operation=HttpActionBinding.ExecuteBindingAsync, Exception=System.ArgumentException: An item with the same key has already been added.
mscorlib.dll!System.ThrowHelper.ThrowArgumentException(System.ExceptionResource resource) Line 74 + 0x2f bytes C#
> mscorlib.dll!System.Collections.Generic.Dictionary<string,System.Web.Http.Metadata.Providers.AssociatedMetadataProvider<System.Web.Http.Metadata.Providers.CachedDataAnnotationsModelMetadata>.PropertyInformation>.Insert(string key, System.Web.Http.Metadata.Providers.AssociatedMetadataProvider<System.Web.Http.Metadata.Providers.CachedDataAnnotationsModelMetadata>.PropertyInformation value, bool add) Line 329 + 0xa bytes C#
mscorlib.dll!System.Collections.Generic.Dictionary<System.__Canon,System.__Canon>.Add(System.__Canon key, System.__Canon value) Line 185 + 0xb bytes C#
System.Web.Http.dll!System.Web.Http.Metadata.Providers.AssociatedMetadataProvider<System.Web.Http.Metadata.Providers.CachedDataAnnotationsModelMetadata>.CreateTypeInformation(System.Type type) + 0x26e bytes
System.Web.Http.dll!System.Web.Http.Metadata.Providers.AssociatedMetadataProvider<System.Web.Http.Metadata.Providers.CachedDataAnnotationsModelMetadata>.GetTypeInformation(System.Type type) + 0x5b bytes
System.Web.Http.dll!System.Web.Http.Metadata.Providers.AssociatedMetadataProvider<System.Web.Http.Metadata.Providers.CachedDataAnnotationsModelMetadata>.GetMetadataForPropertiesImpl.MoveNext() + 0x111 bytes
System.Web.Http.dll!System.Web.Http.Validation.DefaultBodyModelValidator.ValidateProperties(System.Web.Http.Metadata.ModelMetadata metadata, System.Web.Http.Validation.DefaultBodyModelValidator.ValidationContext validationContext) + 0x152 bytes
System.Web.Http.dll!System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(System.Web.Http.Metadata.ModelMetadata metadata, System.Web.Http.Validation.DefaultBodyModelValidator.ValidationContext validationContext, object container) + 0x11b bytes
System.Web.Http.dll!System.Web.Http.Validation.DefaultBodyModelValidator.ValidateProperties(System.Web.Http.Metadata.ModelMetadata metadata, System.Web.Http.Validation.DefaultBodyModelValidator.ValidationContext validationContext) + 0x13b bytes
System.Web.Http.dll!System.Web.Http.Validation.DefaultBodyModelValidator.ValidateNodeAndChildren(System.Web.Http.Metadata.ModelMetadata metadata, System.Web.Http.Validation.DefaultBodyModelValidator.ValidationContext validationContext, object container) + 0x11b bytes
System.Web.Http.dll!System.Web.Http.Validation.DefaultBodyModelValidator.Validate(object model, System.Type type, System.Web.Http.Metadata.ModelMetadataProvider metadataProvider, System.Web.Http.Controllers.HttpActionContext actionContext, string keyPrefix) + 0x29c bytes
System.Web.Http.dll!System.Web.Http.ModelBinding.FormatterParameterBinding.ExecuteBindingAsync.AnonymousMethod__0(object model) + 0xb8 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.Then<object>.AnonymousMethod__35() + 0x49 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.ToAsyncVoidTask.AnonymousMethod__48() + 0x23 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpers.RunSynchronously<System.Threading.Tasks.TaskHelpersExtensions.AsyncVoid>(System.Func<System.Threading.Tasks.Task<System.Threading.Tasks.TaskHelpersExtensions.AsyncVoid>> func, System.Threading.CancellationToken cancellationToken) + 0x64 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.ToAsyncVoidTask(System.Action action) + 0x87 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.Then<object>.AnonymousMethod__34(System.Threading.Tasks.Task<object> t) + 0xba bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.ThenImpl<System.Threading.Tasks.Task<object>,System.Threading.Tasks.TaskHelpersExtensions.AsyncVoid>(System.Threading.Tasks.Task<object> task, System.Func<System.Threading.Tasks.Task<object>,System.Threading.Tasks.Task<System.Threading.Tasks.TaskHelpersExtensions.AsyncVoid>> continuation, System.Threading.CancellationToken cancellationToken, bool runSynchronously) + 0xf2 bytes
System.Web.Http.dll!System.Threading.Tasks.TaskHelpersExtensions.Then<object>(System.Threading.Tasks.Task<object> task, System.Action<object> continuation, System.Threading.CancellationToken cancellationToken, bool runSynchronously) + 0xfb bytes
System.Web.Http.dll!System.Web.Http.ModelBinding.FormatterParameterBinding.ExecuteBindingAsync(System.Web.Http.Metadata.ModelMetadataProvider metadataProvider, System.Web.Http.Controllers.HttpActionContext actionContext, System.Threading.CancellationToken cancellationToken) + 0x193 bytes
System.Web.Http.OData.dll!System.Web.Http.OData.PerRequestParameterBinding.ExecuteBindingAsync(System.Web.Http.Metadata.ModelMetadataProvider metadataProvider, System.Web.Http.Controllers.HttpActionContext actionContext, System.Threading.CancellationToken cancellationToken) Line 49 + 0x16 bytes C#
System.Web.Http.dll!System.Web.Http.Controllers.HttpActionBinding.ExecuteBindingAsync.AnonymousMethod__0(System.Web.Http.Controllers.HttpParameterBinding parameterBinder) + 0x4a bytes


The problem here is because XElement has its own type descriptor which will add additional property descriptors together with reflection based property descriptors. Unfortunately, there are some descriptors having duplicate names, like Value property.

Per HongMei: The bug is in the MediaTypeFormatterCollection.IsTypeExcludedFromValidation() where we were exclude things like JObject and xmlNode from validation, and we should add XElement in the list.

Comments: Verified.
↧

Closed Issue: ~/ url resolution [58]

June 6, 2013, 11:40 am
$
0
0
@Razor 2 "~/" is not exactly Url.Content()
I've had a wiered scenario where I created new Site in IIS and mapped 2 applications to 2 different sites /old/ and /new/. Also I've set up some rewriting rules for homepage to rewrite to /new/ and other urls to map to /old/{R:0}

half or resources in "homepage" were rendered as src="@Url.Content("~/somethn")"
and they were pointing to correct urls, but modernizr were referenced as "~/somethn" and url rendered in the page were "/new/somethn" instead of "/somethn"

When I replaced it with @Url.Content("~/somethn") it rendered just fine as it should.


Comments: Talked to Andrew, but he haven't received any repro yet. Please reopen this bug once we have the repro.
↧
Search

Closed Feature: Fully support JSON light [664]

June 7, 2013, 2:16 pm
$
0
0
Currently we only support some payload kinds and some metadata levels and only writing. We should support the remaining payload kinds, metadata levels (minimal, no, streaming=true) and reading.
↧

Closed Feature: ASP.NET web API $expand [803]

June 7, 2013, 2:19 pm
$
0
0
From reviewing the release notes and other available documentation, and based on some testing a few weeks ago with the source for web API odata, it seems that $expand is not supported, but there seems to be some intention to support it.

Can you provide info on when it will be supported? And ideally an example on how to implement $expand within the Web API odata framework?

This is a major driver for me on the WCF data services vs Web API implementation decision - joining everything on the client, and requiring multiple sequential requests is not acceptably performant or productive. I'd prefer to move to Web API given the extensibility, the fact that it's open-source, and my view that it has a bright future bridging thick and thin client applications.
Comments: verified
↧
↧

Closed Issue: ODataFormatters should share the serializer and deserializer providers [737]

June 7, 2013, 2:21 pm
$
0
0
serializer and deserializer providers cache the serializers. It would be better if we can avoid multiple copies of them.
Comments: verified
↧

Closed Unassigned: Batching handlers should copy properties from batch request to dynamically created requests. [996]

June 7, 2013, 2:21 pm
$
0
0
WebApi-on-Owin's HttpMessageHandlerAdapter populates following properties on an incoming request:

MS_RetrieveClientCertificateDelegate
MS_IsLocal

When a batching request comes in these are populated on the batching request, but we should also copy these properties onto all the dynamically created requests that we create at the batching handler.

This is so that a user expecting a certain property in a request shouldn't see different behavior when the action is invoked as a regular single request or as part of a batch request.

This problem should be happening on SelfHost and WebHosts too.

__Attached__ a standalone Katana repro.
Comments: Verified
↧

Closed Feature: missing serializer for entityreferencelinks [694]

June 7, 2013, 2:22 pm
$
0
0
we need to serialize Uri[] to entityreferencelinks.
Comments: verified
↧
Viewing all 7215 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>