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

Commented Issue: Razor V2 Bug:Url Resolution Fails if you have Html Comment with Quotation or Apostrophe [933]

July 25, 2013, 1:39 pm
$
0
0
During discussing a thread in ASP.NET MVC forums, found a bug in Razor V2 in which the auto url resolution(~) will not work if you have an html comment with quotation or apostrophe before the url resolution(~) tag. Here is an quick example,
``` Html
<!-- '" -->
<img src="~/images/submit.png" />
```

See this thread,
[http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content](http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content)
Comments: Verified again that this bug is solved as well. Unit tests have been checked in. The expected generated code (the .cs file) should Emit something like the following: WriteAttribute("src", Tuple.Create(" src=\"", 4), Tuple.Create("\"", 29) , Tuple.Create(Tuple.Create("", 10), Tuple.Create<System.Object, System.Int32>(Href("~/images/submit.png") , 10), false) ); In order to verify you have to replace the whole stack to MVC5/Razor3 and not just system.web.razor
↧
Search

Commented Issue: Razor bug parsing HTML [710]

July 25, 2013, 1:42 pm
$
0
0
Razor in MVC has a bug when parsing HTML comments with an apostrophe in them. The engine throws an "Expected }" exception.

Below is an example on how to reproduce this issue in the default MVC 4 application with VS 2012. Just add the following a comment with an apostrophe to the @section featured {} in the default.cshtml. Remove the apostrophe from the comment and it works OK.

@section featured {
<!-- hello world it's not cool -->
<section class="featured">
<div class="content-wrapper">
<hgroup class="title">
<h1>@ViewBag.Title.</h1>
<h2>@ViewBag.Message</h2>
</hgroup>
<p>...</p>
</div>
</section>
}

http://stackoverflow.com/a/13864352/446681
Comments: Yeurch - Reverified this is actually resolves 933 as well. Unit tests have been checked in and we verified as follows in VS2013: New MVC5 project Add image with src="~/something" Make sure the image renders Do the same with <!-- ' --> above the image tag. Make sure the image renders.
↧
↧

Commented Issue: [MvcAttributeRouting]Value from ActionName attribute not being considered when building routes [1119]

July 25, 2013, 3:38 pm
$
0
0
For the below action:

```
[RoutePrefix("Home")]
public class HomeController : Controller
{
[HttpGet("Index")]
[ActionName("Default")]
public ActionResult Index()
{
return View();
}
}
```

the route generated is like below:
config.Routes.MapRoute("routeName", "Home/Index", new { controller = "Home", action = "__Index__" }, new { httpMethod = HttpMethodConstraints[GET] });

__Impact__:
Medium. Users use "Url.Action(actionName)" to generate links.

__Workaround__:
Rename the action to be "Default"

__Expected__: action variable value should be "Default"

__Actual__: action variable value is "Index"
Comments: Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/9708c15685ddf9cca9de80afce5842887e9dcac2
↧

Edited Issue: [MvcAttributeRouting]Value from ActionName attribute not being considered when building routes [1119]

July 25, 2013, 3:38 pm
$
0
0
For the below action:

```
[RoutePrefix("Home")]
public class HomeController : Controller
{
[HttpGet("Index")]
[ActionName("Default")]
public ActionResult Index()
{
return View();
}
}
```

the route generated is like below:
config.Routes.MapRoute("routeName", "Home/Index", new { controller = "Home", action = "__Index__" }, new { httpMethod = HttpMethodConstraints[GET] });

__Impact__:
Medium. Users use "Url.Action(actionName)" to generate links.

__Workaround__:
Rename the action to be "Default"

__Expected__: action variable value should be "Default"

__Actual__: action variable value is "Index"
↧

Edited Feature: Support ODataMediaTypeFormatter usage by HttpClient [1140]

July 25, 2013, 3:50 pm
$
0
0
My company expects to implement IIS hosted Web APIs that run on app servers. These will be called by IIS hosted web applications that run on web servers.

We can therefore use ApiControllers on the app servers and call them from HttpClient from the web servers. I like this programming model, where we use the same MediaTypeFormatter and extensibility points at both ends of the wire.

We expect to use EntitySetController endpoints wherever we can, for general CRUD operations, using the JSON light format. Then fall back to ApiControllers if we have to - for operations like IN queries that OData doesn't support.

Ideally I'd like to be able to the following. These may need to use different wire formats (maybe JSON.Net and JSON light). However, I don't want to have to use a DataServiceContext to call EntitySetController, since supporting two entirely different client side programming models adds a lot of work.

* Use the HttpClient to talk to an ApiController
* Use the HttpClient to talk to an EntitySetController

I think I'm right in saying that the second case requires the client to use the ODataMediaTypeFormatter, and the client needs to provide an IEdmModel via the HttpRequestMessage.SetEdmModel method. However, I've been unable to get this to work, with various formatter / serialization problems.

If this supported currently, and if so can anyone point me to some sample code? Any help appreciated.
↧
↧

Commented Feature: Support ODataMediaTypeFormatter usage by HttpClient [1140]

July 25, 2013, 3:50 pm
$
0
0
My company expects to implement IIS hosted Web APIs that run on app servers. These will be called by IIS hosted web applications that run on web servers.

We can therefore use ApiControllers on the app servers and call them from HttpClient from the web servers. I like this programming model, where we use the same MediaTypeFormatter and extensibility points at both ends of the wire.

We expect to use EntitySetController endpoints wherever we can, for general CRUD operations, using the JSON light format. Then fall back to ApiControllers if we have to - for operations like IN queries that OData doesn't support.

Ideally I'd like to be able to the following. These may need to use different wire formats (maybe JSON.Net and JSON light). However, I don't want to have to use a DataServiceContext to call EntitySetController, since supporting two entirely different client side programming models adds a lot of work.

* Use the HttpClient to talk to an ApiController
* Use the HttpClient to talk to an EntitySetController

I think I'm right in saying that the second case requires the client to use the ODataMediaTypeFormatter, and the client needs to provide an IEdmModel via the HttpRequestMessage.SetEdmModel method. However, I've been unable to get this to work, with various formatter / serialization problems.

If this supported currently, and if so can anyone point me to some sample code? Any help appreciated.
Comments: Hi Gary, this is something we'd like to look into in a future version. In the meantime we recommend using the WCF Data Services client to talk to the Web API OData service. An alternative is to use ODataLib directly, which in the end is what Web API OData uses to implement the OData functionality.
↧

Edited Feature: Add support for Spatial Data types in OData [1010]

July 25, 2013, 3:51 pm
$
0
0
Currently, there is no support for spatial data types in Web API OData. Consider adding support for this as it makes impossible to develop any service that has to deal with spatial data.
↧

Edited Issue: [OData] Add support for including non-key properties as well in the SelectExpand expression [1017]

July 25, 2013, 3:53 pm
$
0
0
We include the properties that the client has asked for (thorugh $select and $expand) and the entity keys in the projection expression we generate in the SelectExpandBinder.

If people customize their OData link generation, they might need to access to other properties as well. For example, lets say a Person entity has Id (key) and a Name, and, the generated links contain Name instead of Id.

We should add a setting on ODataQuerySettings to let people choose extra properties that they want to bring from their database.
↧
Search

Edited Issue: Consider supporting parsing and generating key values in KeyValuePathSegment [674]

July 25, 2013, 3:54 pm
$
0
0
So user doesn't need to call ODataUriUtils.ConvertToUriLiteral or ODataUriUtils.ConvertFromUriLiteral to parse the id by himself.
↧
↧

Edited Issue: '/', '\' and ' ' is not handled correctly in string primary key in edit link [498]

July 25, 2013, 3:57 pm
$
0
0
'/', '\' can't route to the correct action
' ' will be null value when binding to the id parameter.

Repro code:
public static void RegisterODataRoutes(this HttpConfiguration configuration)
{
// Metadata routes to support $metadata and code generation in the WCF Data Service client.
configuration.Routes.MapHttpRoute(ODataRouteNames.Metadata, "$metadata", new { Controller = "ODataMetadata", Action = "GetMetadata" });
configuration.Routes.MapHttpRoute(ODataRouteNames.ServiceDocument, string.Empty, new { Controller = "ODataMetadata", Action = "GetServiceDocument" });

// Relationship routes (notice the parameters is {type}Id not id, this avoids colliding with GetById(id)).
configuration.Routes.MapHttpRoute(ODataRouteNames.PropertyNavigation, "{controller}({parentId})/{navigationProperty}");

// Route for manipulating links.
//configuration.Routes.MapHttpRoute(ODataRouteNames.Link, "{controller}({id})/$links/Products");
configuration.Routes.MapHttpRoute(ODataRouteNames.Link, "{controller}({id})/$links/{navigationProperty}");

// Routes for urls both producing and handling urls like ~/Product(1), ~/Products() and ~/Products
configuration.Routes.MapHttpRoute("GetByStringId", "{controller}('{id}')");
configuration.Routes.MapHttpRoute(ODataRouteNames.GetById, "{controller}({id})");
configuration.Routes.MapHttpRoute(ODataRouteNames.DefaultWithParentheses, "{controller}()");
configuration.Routes.MapHttpRoute(ODataRouteNames.Default, "{controller}");
}

[EntitySetAttribute("todo")]
[DataServiceKeyAttribute("Name")]
public class Todo
{
[Key]
public string Name { get; set; }
}

public class TodoController : ApiController
{
static TodoController()
{
var todoes = new List<Todo>();
foreach (var c in "/ \\")
{
todoes.Add(new Todo()
{
Name = c.ToString()
});
}
Todoes = todoes;
}

public static IEnumerable<Todo> Todoes { get; set; }

public IEnumerable<Todo> Get()
{
return Todoes;
}

public Todo GetById(string id)
{
return Todoes.FirstOrDefault(t => t.Name == id);
}

[AcceptVerbs("Merge")]
public Todo Put(string id, Todo todo)
{
todo = Todoes.FirstOrDefault(t => t.Name == id);
return todo;
}
}

Client code:
[Fact]
public void TestSpecialCharacters()
{
DataServiceContext ctx = new DataServiceContext(new Uri(this.BaseAddress));
var todoes = ctx.CreateQuery<Todo>("todo").ToList();

foreach (var todo in todoes)
{
Uri selfLink;
Assert.True(ctx.TryGetUri(todo, out selfLink));
Console.WriteLine(selfLink);

ctx.UpdateObject(todo);

var response = ctx.SaveChanges().Single();

Assert.Equal(200, response.StatusCode);
}
}
↧

Commented Issue: Serializing IQueryable doesn't work [1166]

July 26, 2013, 10:34 am
$
0
0
When trying a query like

/prefix/Customers?$expand=Orders

and having the following body:

```
IQueryable result = options.ApplyTo(customers);
if (result.ElementType != null && typeof(IEdmObject).IsAssignableFrom(result.ElementType))
{
IQueryable<IEdmEntityObject> edmObjects = result as IQueryable<IEdmEntityObject>;
return Ok(edmObjects);
}
else
{
return Ok(result as IQueryable<Customer>);
}
```

the result is a 406, when it should be 200 and the serialized feed.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/e18760b301e9632eb3731497b49ace5f732bdabb).
↧

Edited Issue: Serializing IQueryable doesn't work [1166]

July 26, 2013, 10:34 am
$
0
0
When trying a query like

/prefix/Customers?$expand=Orders

and having the following body:

```
IQueryable result = options.ApplyTo(customers);
if (result.ElementType != null && typeof(IEdmObject).IsAssignableFrom(result.ElementType))
{
IQueryable<IEdmEntityObject> edmObjects = result as IQueryable<IEdmEntityObject>;
return Ok(edmObjects);
}
else
{
return Ok(result as IQueryable<Customer>);
}
```

the result is a 406, when it should be 200 and the serialized feed.
↧

Commented Issue: Consider changing the default value for MaxExpansionDepth to be more permisive [1161]

July 26, 2013, 10:39 am
$
0
0
The default value for MaxExpansionDepth in Web API is set to 1. Although this works on most of the cases, having a default expansion value of two is much more reasonable, as it can cover scenarios like a client querying for a Customer, it's related Orders and the Details for those orders.

In the Web API preview, there wasn't support for nested server pagination of a IQueryable, so this limit had to be very conservative as it could cause a serious performance penalty on the service As nested pagination has been implemented for RTM, it makes sense to be more permissive with this limit, as for example, if we stablish a page size of 10, and an expansion depth of 2, the maximum number of objects that a client could retrieve in one request would be 1110 considering he sends a query like query?$expand=Orders/Details
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/63ca1bbfa6726ca83d9470a285621835fe208823).
↧
↧

Edited Issue: Consider changing the default value for MaxExpansionDepth to be more permisive [1161]

July 26, 2013, 10:39 am
$
0
0
The default value for MaxExpansionDepth in Web API is set to 1. Although this works on most of the cases, having a default expansion value of two is much more reasonable, as it can cover scenarios like a client querying for a Customer, it's related Orders and the Details for those orders.

In the Web API preview, there wasn't support for nested server pagination of a IQueryable, so this limit had to be very conservative as it could cause a serious performance penalty on the service As nested pagination has been implemented for RTM, it makes sense to be more permissive with this limit, as for example, if we stablish a page size of 10, and an expansion depth of 2, the maximum number of objects that a client could retrieve in one request would be 1110 considering he sends a query like query?$expand=Orders/Details
↧

Commented Unassigned: [AttributeRouting]Route not being added to route collection [1005]

July 26, 2013, 11:16 am
$
0
0
In the following scenario, the Get() action on ReproController, which is decorated with an attribute route is _not_ being added to the route collection.

On the other hand, the Get() action on the WorkingConroller is added to the route collection as expected.

Expected: Get() action on ReproController should be part of route collection
Actual: Not added to route collection.

```
public class ReproController : ApiController
{
//NOTE: NOT added to route collection
[HttpGet(RouteName="GetAllValues")]
public string Get()
{
return "Repro.GetAllValues";
}
}

public class WorkingController : ApiController
{
//NOTE: ADDED to route collection. Notice the empty route template
[HttpGet("", RouteName = "GetAllValues2")]
public string Get()
{
return "Working.GetAllValues2";
}
}
```
Comments: Need to throw an exception if RouteName or RouteOrder is set when there is no route template
↧
Search

Commented Unassigned: [WebApiOnOwin]Provide IAppBuilder extension which accepts HttpServer [1025]

July 26, 2013, 11:19 am
$
0
0
Scenario: Use Web API request batching on Owin.

Our DefaultHttpBatchHandler requires us to supply the HttpServer instance to it, so I cannot use the 'UseWebApi' extension here. So, I am using the 'UseMessageHandler' extension:

```
public void Configuration(IAppBuilder appBuilder)
{
HttpConfiguration config = new HttpConfiguration();
config.Services.Replace(typeof(IHostBufferPolicySelector), new CustomBufferPolicySelector());

HttpServer server = new HttpServer(config);

config.MapHttpAttributeRoutes();
config.Routes.MapHttpBatchRoute("batchRoute", "api/$batch", new DefaultHttpBatchHandler(httpServer: server));

appBuilder.UseHttpMessageHandler(messageHandler: server);
}
```

Also the 'UseHttpMessageHandler' (below) uses the default buffer policy selector and does not take the buffer policy from the configuration of HttpServer

```
/// <summary>
/// Adds a component to the OWIN pipeline for running an <see cref="HttpMessageHandler"/>.
/// </summary>
/// <param name="builder">The application builder.</param>
/// <param name="messageHandler">The message handler.</param>
/// <returns>The application builder.</returns>
public static IAppBuilder UseHttpMessageHandler(this IAppBuilder builder, HttpMessageHandler messageHandler)
{
return builder.Use(typeof(HttpMessageHandlerAdapter), messageHandler, _defaultBufferPolicySelector);
}
```

We need a convenient extension for users to be able to supply the HttpServer instance.
Comments: I don't think this is ever worth adding.
↧

Commented Feature: Please readd FormatterContext [221]

July 26, 2013, 11:26 am
$
0
0
Hello there,

today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.

Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.

Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.

Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.

At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.

With best regards,
Kay
Comments: We need a re-design of the formatter interface. We need to define a new IServerFormatter (or some similar name) with the following changes: 1) Use IEnumerable or IList instead of Collection for collection properties to allow for more performant implementations 2) Add request/response information to ReadFromStreamAsync/WriteToStreamAsync 3) Add cancellation token to ReadFromStreamAsync/WriteToStreamAsync to allow formatters to abort reads/writes 4) Get rid of as much unnecessary overhead as possible - e.g., GetPerRequestFormatterInstance
↧
↧

Commented Feature: Please readd FormatterContext [221]

July 26, 2013, 11:42 am
$
0
0
Hello there,

today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.

Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.

Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.

Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.

At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.

With best regards,
Kay
Comments: 5) CanWriteType should be CanWriteObject(object instance) to allow a formatter to handle only certain instances of a type
↧

Created Unassigned: MQ: Move StyleCop build logic out into a NuGet package [1170]

July 26, 2013, 11:45 am
$
0
0
Instead of having a custom, private copy of StyleCop build logic (WebStack.StyleCop.targets), create a standard StyleCop targets NuGet package (that could be shared by others projects such as EF). Also see if the StyleCop owners would consider taking ownership of this package.
↧

Created Unassigned: MQ: Move xUnit build logic out into a NuGet package [1171]

July 26, 2013, 11:48 am
$
0
0
Instead of having a custom, private copy of xUnit build system (test runner) logic (WebStack.xunit.targets), create a standard xUnit targets NuGet package (and share it with other projects such as EF). Also see if the xUnit owners would consider taking ownership of this package.

Note that the EF team is interested in this work as well and might be done in collaboration with them.
↧
Viewing all 7215 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>