MVC currently bundles version 1.10 from September 2012, the latest is 1.11.1 from March 2013.
↧
Created Task: JQuery validation plugin - version upgrade [1058]
↧
Created Issue: Validation - consider using FileExtensionsAttribute from System.ComponentModel.DataAnnotations [1059]
The said attribute is new in .net 4.5
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
↧
↧
Commented Feature: $format is not supported [582]
ODATA services should support $format ($format=json and $format=atom) query string parameters.
As described here http://www.odata.org/documentation/uri-conventions#FormatSystemQueryOption .
Comments: Actually solution proposed by raghuramn does not work. I tried these variants: config.Formatters.XmlFormatter.AddQueryStringMapping("$format", "xml", "application/atom+xml"); config.Formatters.XmlFormatter.MediaTypeMappings.Add(new QueryStringMapping("$format", "xml", "application/atom+xml")); And both of them do not work. The only way that works for me I found in this post http://stackoverflow.com/questions/16455501/why-doesnt-my-odata-response-have-navigation-properties Post above has another reference to https://gist.github.com/raghuramn/5556691 by RaghuRam Nadiminti. RaghuRam Nadiminti advised to add custom handler into config.MessageHandlers that could override Accept header. So question, is advise about formatters actual?
As described here http://www.odata.org/documentation/uri-conventions#FormatSystemQueryOption .
Comments: Actually solution proposed by raghuramn does not work. I tried these variants: config.Formatters.XmlFormatter.AddQueryStringMapping("$format", "xml", "application/atom+xml"); config.Formatters.XmlFormatter.MediaTypeMappings.Add(new QueryStringMapping("$format", "xml", "application/atom+xml")); And both of them do not work. The only way that works for me I found in this post http://stackoverflow.com/questions/16455501/why-doesnt-my-odata-response-have-navigation-properties Post above has another reference to https://gist.github.com/raghuramn/5556691 by RaghuRam Nadiminti. RaghuRam Nadiminti advised to add custom handler into config.MessageHandlers that could override Accept header. So question, is advise about formatters actual?
↧
Edited Issue: Validation - consider using FileExtensionsAttribute from System.ComponentModel.DataAnnotations [1059]
The said attribute is new in .net 4.5
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
↧
Edited Issue: JQuery Validation plugin - include additional-methods file [1057]
The JQuery Validation plugin is normally bundled with a file named additional-methods.js that adds some more validation methods to the basic ones that are in the plugin.
Two of which, 'accept' (for validating mime-types on input[type=file]) and 'extension' for validating file extensions (again, on input[type=file]), have support within MVC in the form of validation attributes (FileExtensionsAttribute and AcceptAttribute)
Currently the templates provided does not include that additional file, hence out-of-the-box these validation attributes only apply on server-side.
A fix would be to either add the nuget-package for the additional methods into the template, or to update the JQuery.validation nuget package to always include the additional methods file.
The default Bundle for jquaeyval should be updated as well.
Two of which, 'accept' (for validating mime-types on input[type=file]) and 'extension' for validating file extensions (again, on input[type=file]), have support within MVC in the form of validation attributes (FileExtensionsAttribute and AcceptAttribute)
Currently the templates provided does not include that additional file, hence out-of-the-box these validation attributes only apply on server-side.
A fix would be to either add the nuget-package for the additional methods into the template, or to update the JQuery.validation nuget package to always include the additional methods file.
The default Bundle for jquaeyval should be updated as well.
↧
↧
Created Unassigned: [HelpPage]Do not display parameter info when action parameter is HttpRequestMessage [1060]
For the following action, we are currently displaying parameter info(attached an snapshot image) in help page:
```
public IEnumerable<string> Get(HttpRequestMessage request)
{
return new string[] { "value1", "value2" };
}
```
We should avoid displaying this information as from end user's perspective, it doesn't make sense.
We already do not show parameter info for parameter CancellationToken. We could add one more check for HttpRequestMessage too.
In "\Areas\HelpPage\Views\Help\DisplayTemplates\Parameters.cshtml":
```
// Don't show CancellationToken because it's a special parameter
if (!typeof(CancellationToken).IsAssignableFrom(parameter.ParameterDescriptor.ParameterType))
{
```
```
public IEnumerable<string> Get(HttpRequestMessage request)
{
return new string[] { "value1", "value2" };
}
```
We should avoid displaying this information as from end user's perspective, it doesn't make sense.
We already do not show parameter info for parameter CancellationToken. We could add one more check for HttpRequestMessage too.
In "\Areas\HelpPage\Views\Help\DisplayTemplates\Parameters.cshtml":
```
// Don't show CancellationToken because it's a special parameter
if (!typeof(CancellationToken).IsAssignableFrom(parameter.ParameterDescriptor.ParameterType))
{
```
↧
Created Unassigned: Make ODataQueryOptions behave more like a property [1061]
As of right now, every time the user calls EntitySetController.QueryOptions we create a new instance of ODataQueryOptions<T>.
This causes some problems when the user calls it several times and makes changes on one of the instances as the customer expects the same instance to be returned every time he calls EntitySetController.QueryOptions.
This causes some problems when the user calls it several times and makes changes on one of the instances as the customer expects the same instance to be returned every time he calls EntitySetController.QueryOptions.
↧
Commented Issue: Add support for conditional attributes in the Html helpers [476]
Today, if a user puts the following in a CSHTML page:
@Html.TextBox("myname", "mytext", new { disabled = isDisabled })
this will render a "disabled" attribute whose value will be set to True or False. This is inconsistent with HTML's handling of boolean attributes, and it's also inconsistent with the work we did in Razor v2 to support conditional attributes in Razor markup.
This suggestion is to add conditional attribute logic to the Html helpers so the above would conditionally display the disabled attribute (provided that isDisabled is a boolean).
Comments: I think this should also handle null values as asked in [this StackOverflow question](http://stackoverflow.com/questions/16673903/inconsistent-null-attribute-handling-in-asp-net-mvc-4).
@Html.TextBox("myname", "mytext", new { disabled = isDisabled })
this will render a "disabled" attribute whose value will be set to True or False. This is inconsistent with HTML's handling of boolean attributes, and it's also inconsistent with the work we did in Razor v2 to support conditional attributes in Razor markup.
This suggestion is to add conditional attribute logic to the Html helpers so the above would conditionally display the disabled attribute (provided that isDisabled is a boolean).
Comments: I think this should also handle null values as asked in [this StackOverflow question](http://stackoverflow.com/questions/16673903/inconsistent-null-attribute-handling-in-asp-net-mvc-4).
↧
Edited Issue: PushstreamContent in Win8 App is not working [324]
I am hitting an issue with using PushStreamContent in the Windows store app. I don’t see the same issue in the traditional console app though.
It’s a simple scenario where I am ‘POST’ing some small data to a service using PushStreamContent as below.
HttpClient client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Post, "http://.../SimpleMvcWebAPIApplication/api/values");
request.Content = new PushStreamContent((stream, httpContent, transportContext) =>
{
using (var streamWriter = new StreamWriter(stream))
{
string data = "\"hello world\"";
streamWriter.Write(data);
streamWriter.Flush();
}
}, "application/json");
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
It fails as below.
System.ObjectDisposedException was unhandled by user code
HResult=-2146232798
Message=Cannot access a closed Stream.
Source=mscorlib
ObjectName=""
StackTrace:
at System.IO.__Error.StreamIsClosed()
at System.IO.MemoryStream.Seek(Int64 offset, SeekOrigin loc)
at System.Net.Http.HttpContent.<>c__DisplayClassf.<LoadIntoBufferAsync>b__d(Task copyTask)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at App5.App.<SimpleWebAPIService_Write_Temp1>d__f.MoveNext() in c:\personal\maying\WinRT\client\WinRTClient\App.xaml.cs:line 368
InnerException:
It’s a simple scenario where I am ‘POST’ing some small data to a service using PushStreamContent as below.
HttpClient client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Post, "http://.../SimpleMvcWebAPIApplication/api/values");
request.Content = new PushStreamContent((stream, httpContent, transportContext) =>
{
using (var streamWriter = new StreamWriter(stream))
{
string data = "\"hello world\"";
streamWriter.Write(data);
streamWriter.Flush();
}
}, "application/json");
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
It fails as below.
System.ObjectDisposedException was unhandled by user code
HResult=-2146232798
Message=Cannot access a closed Stream.
Source=mscorlib
ObjectName=""
StackTrace:
at System.IO.__Error.StreamIsClosed()
at System.IO.MemoryStream.Seek(Int64 offset, SeekOrigin loc)
at System.Net.Http.HttpContent.<>c__DisplayClassf.<LoadIntoBufferAsync>b__d(Task copyTask)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at App5.App.<SimpleWebAPIService_Write_Temp1>d__f.MoveNext() in c:\personal\maying\WinRT\client\WinRTClient\App.xaml.cs:line 368
InnerException:
↧
↧
Edited Issue: ASP.NET Web API does not call GetRouteData for custom HttpRoutes [453]
Here is the issue explained and a repro http://stackoverflow.com/questions/12544150/asp-net-web-api-rtm-and-subdomain-routes
↧
Edited Unassigned: Provide a way to specify actual return type for actions returning IHttpActionResult. [1045]
OData and HelpPage areas are effected by this:
__OData__
__Error__:
{"Message":"An error has occurred.","ExceptionMessage":"Cannot create an EDM model as the action 'Get' on controller 'Customers' has a return type 'System.Web.Http.IHttpActionResult' that does not implement IEnumerable<T>.","ExceptionType":"System.InvalidOperationException","StackTrace":" at System.Web.Http.ApiController.<InvokeActionWithExceptionFilters>d__a.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\ApiController.cs:line 355\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Tracing.Tracers.HttpControllerTracer.<ExecuteAsyncCore>d__5.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\Tracers\\HttpControllerTracer.cs:line 88\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Tracing.ITraceWriterExtensions.<TraceBeginEndAsyncCore>d__21`1.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Tracing\\ITraceWriterExtensions.cs:line 535\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__0.MoveNext() in c:\\WebstackRuntime\\Runtime\\src\\System.Web.Http\\Dispatcher\\HttpControllerDispatcher.cs:line 69"}
__Code__:
```
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public int Age { get; set; }
}
public class CustomersController : ApiController
{
public IHttpActionResult Get(ODataQueryOptions opts)
{
List<Customer> customers = new List<Customer>();
customers.Add(new Customer()
{
Id = 1,
Age = 31,
Name = "John"
});
customers.Add(new Customer()
{
Id = 2,
Age = 42,
Name = "Mike"
});
customers.Add(new Customer()
{
Id = 6,
Age = 14,
Name = "Abe"
});
IQueryable results = opts.ApplyTo(customers.AsQueryable());
return Content<IQueryable<Customer>>(HttpStatusCode.OK, results as IQueryable<Customer>);
}
}
```
__HelpPage__
HelpPage generates samples based on the return type of the actions. If IHttpActionResult is the declarated return type of the action, then HelPage will not be able to generate samples. This behavior is not something new and users today already would see this experience if someone returns the type HttpResponseMessage.
There is a workaround for this in HelpPage, where users can explicitly set samples for specific actions which return HttpResponseMessage and this workaround could be used for actions returning IHttpActionResult too.
But this workaround would be too cumbersome on users as going forward users might tend to return IHttpActionResult from all their actions due to their easy testability.
David & Yao already have some ideas regarding this and this issue is to keep track of it.
↧
Edited Issue: Document that IValueProvider.GetValue() returns null if the exact key is not found [1056]
Document that IValueProvider.GetValue() returns null if the exact key is not found.
This applies to both MVC and WebAPI versions.
This applies to both MVC and WebAPI versions.
↧
Edited Unassigned: [WebApiOnOwin]Uploading a 2GB file with custom input buffer selector set to true fails [1036]
Repro sample : FileUploadSample (file://KK-MC2/FileUploadSample)
I have a simple custom buffer selector where UseBufferedInputStream returns true.
When I try to upload a 2GB fails, I am seeing a failure with below stack trace.
{"The stream does not support concurrent IO read or write operations."}
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I have a simple custom buffer selector where UseBufferedInputStream returns true.
When I try to upload a 2GB fails, I am seeing a failure with below stack trace.
{"The stream does not support concurrent IO read or write operations."}
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
↧
↧
Edited Unassigned: [WebApiOnOwin]Uploading a 2GB file with custom input buffer selector set to true fails [1036]
Repro sample : FileUploadSample (file://KK-MC2/FileUploadSample)
I have a simple custom buffer selector where UseBufferedInputStream returns true.
When I try to upload a 2GB fails, I am seeing a failure with below stack trace.
{"The stream does not support concurrent IO read or write operations."}
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I have a simple custom buffer selector where UseBufferedInputStream returns true.
When I try to upload a 2GB fails, I am seeing a failure with below stack trace.
{"The stream does not support concurrent IO read or write operations."}
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
↧
Edited Issue: Update the Web API OWIN adapter to use Microsoft.Owin once it behaves well [1054]
Biggest adoption blockers identified so far are:
1. Potential null refs when computing URIs
2. Doesn't throw when required keys are missing from the environment, or when the environment has the wrong type for a particular key
1. Potential null refs when computing URIs
2. Doesn't throw when required keys are missing from the environment, or when the environment has the wrong type for a particular key
↧
Commented Feature: Support IServiceProvider Injection for DataAnnotations validations through DependencyResolver [463]
I am not completely sure but at first glance, it seems to me that IServiceProvider for DataAnnotations validations is completely ignored in ASP.NET Web API.
Here is a quote from
Jeff Handley's blog post (http://jeffhandley.com/archive/2010/10/25/RiaServicesValidationContext.aspx):
"Consider the scenario where a validator needs to access the database; you certainly wouldn’t couple a validation method to your data access layer, would you? Instead, you would make your repository available as a service that your validation method can consume in a loosely-coupled manner. In order to easily support these scenarios, ValidationContext implements IServiceProvider. This interface requires a single method, GetService(Type). Using GetService, a validation method can access your repository without knowing how to instantiate or initialize it."
Here is the Validate method of the DataAnnotationsModelValidator class:
public override IEnumerable<ModelValidationResult> Validate(ModelMetadata metadata, object container)
{
// Per the WCF RIA Services team, instance can never be null (if you have
// no parent, you pass yourself for the "instance" parameter).
ValidationContext context = new ValidationContext(container ?? metadata.Model, null, null);
context.DisplayName = metadata.GetDisplayName();
ValidationResult result = Attribute.GetValidationResult(metadata.Model, context);
if (result != ValidationResult.Success)
{
return new ModelValidationResult[] { new ModelValidationResult { Message = result.ErrorMessage } };
}
return new ModelValidationResult[0];
}
It would be great to inspect the global DependencyResolver and see whether there is any IServiceProvider type registered. If so, you can pass that into ValidationContext instead of passing null.
I am completely unsure if this is possible to implement because at the first glance, it seems that the validation part doesn't have any knowledge of the HttpConfiguration.
Edit:
Also, this would be much more useful for the IValidatableObject validation. A sample use case scenario here is to check an existence of a value inside the database.
Comments: Is there a work around until it is in the core. Is there any way hook into the creation of the ValidationContext from within WebApi?
Here is a quote from
Jeff Handley's blog post (http://jeffhandley.com/archive/2010/10/25/RiaServicesValidationContext.aspx):
"Consider the scenario where a validator needs to access the database; you certainly wouldn’t couple a validation method to your data access layer, would you? Instead, you would make your repository available as a service that your validation method can consume in a loosely-coupled manner. In order to easily support these scenarios, ValidationContext implements IServiceProvider. This interface requires a single method, GetService(Type). Using GetService, a validation method can access your repository without knowing how to instantiate or initialize it."
Here is the Validate method of the DataAnnotationsModelValidator class:
public override IEnumerable<ModelValidationResult> Validate(ModelMetadata metadata, object container)
{
// Per the WCF RIA Services team, instance can never be null (if you have
// no parent, you pass yourself for the "instance" parameter).
ValidationContext context = new ValidationContext(container ?? metadata.Model, null, null);
context.DisplayName = metadata.GetDisplayName();
ValidationResult result = Attribute.GetValidationResult(metadata.Model, context);
if (result != ValidationResult.Success)
{
return new ModelValidationResult[] { new ModelValidationResult { Message = result.ErrorMessage } };
}
return new ModelValidationResult[0];
}
It would be great to inspect the global DependencyResolver and see whether there is any IServiceProvider type registered. If so, you can pass that into ValidationContext instead of passing null.
I am completely unsure if this is possible to implement because at the first glance, it seems that the validation part doesn't have any knowledge of the HttpConfiguration.
Edit:
Also, this would be much more useful for the IValidatableObject validation. A sample use case scenario here is to check an existence of a value inside the database.
Comments: Is there a work around until it is in the core. Is there any way hook into the creation of the ValidationContext from within WebApi?
↧
Edited Issue: Validation - consider using FileExtensionsAttribute from System.ComponentModel.DataAnnotations [1059]
The said attribute is new in .net 4.5
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
We should consider obsoleting out own FileExtensions attribute if the new attribute can be made to work with instances of HttpPostedFileBase (it is currently only for strings)
Otherwise we could consider identifying cases of the .net attribute being set on HttpPostedFileBase properties, and somehow notify the developer about using the correct attribute instead.
↧
↧
Commented Issue: Bundler / minifier not handling end of file comments correctly [884]
I have noticed that the bundler doesn't handle single line comments at the end of a javascript file correctly (or as would be expected), when the script is bundled and minified.
A single line comment at the end of one of the script files, without a line break at the end, affects the content/interpretation of the script of the next file.
Suppose script 1 has:
```
var hello = "Hello";
function SayHelloWorld() {
alert(hello + "World");
}
//=======test comment==========(no line break here)
```
and script two has:
```
function Test()
{
this.a = 1;
}
//===== another comment with no line break at the end=======
```
The resulting script after bundling is:
```
function SayHelloWorld(){alert(hello+"World")}var hello="Hello";this.a=1
```
Notice that constructor function Test() has disappeared and only the contents of that function are placed on the resulting script;
Removing the comment at the end of the file, or adding a line break after it outputs the correct and expected script
```
function SayHelloWorld(){alert(hello+"World")}function Test(){this.a=1}var hello="Hello"
```
about the attatchment: I includes a Bundle.cs (with the bundle definition), the javascript files in the script/testscripts directory, and a modified _layout to include the bundle. This can be copied onto a simple MVC4 internet Application project.
Comments: Same problem here. (With Microsoft ASP.NET Web Optimization Framework 1.0.0) I'm using jquery-migrate package. The jquery-migrate-1.1.1.min.js file have a End-line comment, and this comment broke the minification process.
A single line comment at the end of one of the script files, without a line break at the end, affects the content/interpretation of the script of the next file.
Suppose script 1 has:
```
var hello = "Hello";
function SayHelloWorld() {
alert(hello + "World");
}
//=======test comment==========(no line break here)
```
and script two has:
```
function Test()
{
this.a = 1;
}
//===== another comment with no line break at the end=======
```
The resulting script after bundling is:
```
function SayHelloWorld(){alert(hello+"World")}var hello="Hello";this.a=1
```
Notice that constructor function Test() has disappeared and only the contents of that function are placed on the resulting script;
Removing the comment at the end of the file, or adding a line break after it outputs the correct and expected script
```
function SayHelloWorld(){alert(hello+"World")}function Test(){this.a=1}var hello="Hello"
```
about the attatchment: I includes a Bundle.cs (with the bundle definition), the javascript files in the script/testscripts directory, and a modified _layout to include the bundle. This can be copied onto a simple MVC4 internet Application project.
Comments: Same problem here. (With Microsoft ASP.NET Web Optimization Framework 1.0.0) I'm using jquery-migrate package. The jquery-migrate-1.1.1.min.js file have a End-line comment, and this comment broke the minification process.
↧
Edited Issue: WebAPI ODataLib dependency invalid [1055]
Currently the WebAPI OData package has a dependency on ODataLib >= 5.5.0-alpha2, however if you use ODataLib 5.5.0-rc1 everything breaks.
The MyGet dependency value should probably be set to =5.5.0-alpha2.
The MyGet dependency value should probably be set to =5.5.0-alpha2.
↧
Commented Issue: WebAPI ODataLib dependency invalid [1055]
Currently the WebAPI OData package has a dependency on ODataLib >= 5.5.0-alpha2, however if you use ODataLib 5.5.0-rc1 everything breaks.
The MyGet dependency value should probably be set to =5.5.0-alpha2.
Comments: Fixed in the nightly builds
The MyGet dependency value should probably be set to =5.5.0-alpha2.
Comments: Fixed in the nightly builds
↧