This is the line that is not working:
ModelBinders.Binders.Add(typeof(decimal), new DecimalModelBinder())
To be more precise. Binders is highlated.
I found this article by Phil Haack.
I did all it said, added refrences to using System.Web.Http.ModelBinding.Binders;
Added class public class DecimalModelBinder : IModelBinderto a new folder and told to Global.ascx about the folder. But the red line keeps showing underneath the Binders. Can you help me?
From the error it looks like it is treating the ModelBinders as namespace (which is present in your project) instead of the framework class.
Try using the below line which will resolve the ambiguity.
System.Web.Mvc.ModelBinders.Binders.Add(typeof(decimal), new DecimalModelBinder())
The compiler interprets the reference to ModelBinders as a reference to RoomReservation.Wep.ModelBinders. Try using
System.Web.Http.ModelBinding.Binders.Add(typeof(decimal), new DecimalModelBinder())
Related
I am trying to create an instance of ODataQueryContext which requires an EdmModel reference. I am attempting to get the Model from ODataProperties() which is a method call off of the HttpRequestMessage object.
var orderBy = new OrderByQueryOption("ColumnName desc", new ODataQueryContext(Request.ODataProperties().Model, typeof(MyType)));
It seems that if I use the namespace using System.Web.Http.OData.Extensions; as opposed to using System.Web.OData.Extensions; the Model property is available from ODataProperties(). However, I am using the newer version (OData v4) namespaces, for other references in my program.
After doing some research I determined that with OData v4, they moved everything from Web.Http.OData.* namespaces, to Web.OData.* namespaces. I am assuming that I need to be consistent in using either the new or old namespaces, and I was not successful attempting to mix them.
Does anyone know how to get the Model property from ODataProperties() without using the older Web.Http.OData namespaces?
To anyone still having trouble with this (I ended-up here from a MS OData tutorial) request.ODataProperties().Model has changed to request.GetModel() ( HttpRequestMessageExtensions in namespace Microsoft.AspNet.OData.Extensions in assembly Microsoft.AspNet.OData). Also request.ODataProperties().PathHandler has changed to request.GetPathHandler().
In ASP.NET Core 3.1, package Microsoft.AspNetCore.OData, most values under Request.ODataProperties() are now under Request.ODataFeature().
ODataProperties().Model from OData on github
I'm creating a Web Application on ASP.NET and C#.
The problem I have is that I cannot create a instance of a BLL class on the code behind of a page.
I have the Log In Page (LogIn.aspx) and the page that controls de Log In Page (LogIn.aspx.cs). When I am on LogIn.aspx.cs and I try to do: UsersBLL _users = new UsersBLL(), I get the missing a using directive or assembly reference message.
I can fix it by rigth-clicking on UsersBLL.cs class > Properties > Build Action and changing Content to Compile.
At this point I can create an instance of UsersBLL.cs class on LogIn.aspx.cs, but the class get "broken" and does not recognize any "DataSet Instructions" (refer the image to understand it...)
What should I do to fix it?
Thankyou in advance for your answer!
"Broken" UsersBLL.cs class
You need to check what namespace is defined for your USERSTableAdapter, what is your assembly of this class. Add reference to this assembly. Then add the namespace of the adapter in your class UsersBLL. If this USERSTableAdapter is defined in the current project then only the namespace added required. For more help on using ADO.NET and TableAdapters in Visual Studio see this manual
I've been trying to open a file in asp.net 5 and have not been having a lot of success.
In the past you used Server.MapPath or HostingEnvironment.ApplicationPhysicalPath. They are both gone in the OWIN based framework.
There is a HostingEnvironment class but it's in the System.Aspnet but it needs to be initialized by the hosting environment (it no longer has a static member for ApplicationPhysicalPath but I'm guessing the WebRoot member does that now. The problem is I can't find a reference to it anywhere.
I've also looked at Context.GetFeature<> but it doesn't seem to have any feature that would show the application path, just request and response related info. The code listing the features can be found here.
<snark>Is the ability to work with files a discontinued feature in ASP.NET?</snark>
There is also the possibility that I can't brain very well right now and missed something.
You can get it from the ApplicationBasePath property of Microsoft.Framework.Runtime.IApplicationEnvironment serivce.
Example: https://github.com/aspnet/Mvc/blob/9f1cb655f6bb1fa0ce1c1e3782c43a2d45ca4e37/test/WebSites/FilesWebSite/Controllers/DownloadFilesController.cs#L28
There are two approaches now:
using Microsoft.Extensions.PlatformAbstractions;
public Startup(IApplicationEnvironment appEnv)
{
// approach 1
var path01 = PlatformServices.Default.Application.ApplicationBasePath;
// approach 2
var path02 = appEnv.ApplicationBasePath;
}
We have 2 orgs running in our on-premise crm 2011 system.
We have generated early bound classes for both orgs.
One of our plugins is throwing the "a proxy type with the name account has been defined by another assembly" error when deactivating an account.
That plugin only references one of the early bound dll's.
How do I get the CRM system to respect the namespace of these references.
I've tried the few items that show up from Google and none are working.
Since you can reproduce this with 2 vanilla orgs I would imaging there is something OUTSIDE the code layer we can do without having to go back and refactor a bunch of code for the 2 orgs.
Thanks,
Jon
The problem is actually with WCF attempting to deserialize the server response and not being able to identify the correct type. The best method to sort this issue is to pass in the current assembly using Assembly.GetExecutingAssembly() to the ProxyTypesBehavior() while creating the proxy like so.
using (serviceProxy = new OrganizationServiceProxy(config.OrganizationUri,
config.HomeRealmUri,
config.Credentials,
config.DeviceCredentials))
{
// This statement is required to enable early-bound type support.
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior(Assembly.GetExecutingAssembly()));
}
You may run into this issue when referencing different assemblies containing proxy-classes, i.e. one assembly wrapping the server SDK (Microsoft.Xrm.Sdk) and another assembly wrapping the client SDK (Microsoft.Xrm.Sdk.Client).
In such a scenario it seems to be required to tell the OrganizationServiceProxy which assembly should be used to resolve the proxy classes.
This should help:
var credentials = new ClientCredentials();
credentials.Windows.ClientCredential = new System.Net.NetworkCredential(userName, password, domain);
var proxy = new OrganizationServiceProxy(new Uri(discoveryUrl), null, credentials, null);
proxy.EnableProxyTypes(typeof(CrmServiceContext).Assembly);
var context = CrmServiceContext(proxy);
The important thing is to call EnableProxyTypes by passing the correct assembly. I saw another solution using CrmConnection but CrmConnection is only available in the client SDK, which means that you can't instantiate a "server-OrganizationServiceProxy" this way. EnableProxyTypes(Assembly assembly) works for both sides.
Hope this helps.
Regards,
MH
It maybe years since this question has been raised. However, I faced this problem recently and have been extremely worried about thousands of lines of code to be changed. However, I was lucky to find the following simple change to get myself out of hell:
Suppose there are two context objects you deal with:
an OrganizationServiceContext object: context1
a CrmSvcUtil Context object: context2
and a single OrganizationServiceProxy object: service
if in a single method, you make multiple CRUD operations using the same service object but with either of context objects as exemplified above, it is highly probable that this error be raised. However, by doing the following, you can prevent it to happen.
Every time you want to work with context1, you precede the context object with the service object as following:
service.EnableProxyTypes(typeof(OrganizationServiceContext).Assembly);
using (var context1 = new OrganizationServiceContext(_service)){
// your classic code here
}
Also, every time you want to work with context2, you follow the same structure:
service.EnableProxyTypes(typeof(HiwebContext).Assembly);
using (var context = new XYZContext(this._service)){
// your CrmSvcUtil none-classic code here
}
this normally means that there is one or more assemblies with the same method name or property to fix this use the fully qualified name of the assembly.. for example in the using System.IO for example if you had a method named the same way in your Class code that conflicts with System.IO.... you would write your fix like
thisObject.System.IO.Path( ---- ) = somthing for example.. does this make sense..?
I found that adding the Assembly.GetExecutingAssembly() solved the problem.
adding the Assembly.GetExecutingAssembly() solve my problem, you also need to add using System.Reflection;
thanks
My team is hoping to use the EFPocoAdapter, but are also hoping to use the DynamicData tools with it but are having some issues.
We basically added a "Dynamic Data Entities Web Application" project to the EFPocoAdapter Northwind sample solution (I am using the latest version, 1.03), referenced the needed assemblies and then uncommented and edited the line in the Global.asax.cs file that registers a context with the MetaModel to look like this:
model.RegisterContext(typeof(NorthwindEF.NorthwindEntities),
new ContextConfiguration() { ScaffoldAllTables = true });
We get this error: "The context type 'NorthwindEF.NorthwindEntities' is not supported."
The question we have is, how can we make this a valid context or how else can we hack things to make this work for us?
Any pointers are appreciated, thanks.
You need to add the DynamicData.EFCodeFirstProvider, available from Nuget, just search for EFCodeFirstProvider. Then you use:
DefaultModel.RegisterContext(
new EFCodeFirstDataModelProvider(() => new NorthwindEF.NorthwindEntities()),
new ContextConfiguration() { ScaffoldAllTables = true });