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 });
Related
I am currently working with CRM 2015 SDK. I am simply trying to update a value in C# with this SDK. But for some reasons that I try to figure out, there is a trouble when I save my context.
There is the code :
foreach (KeyValuePair<string, Account> account in dicAccount)
{
//Calcul of url/login/date/key/customer values
string generatedUrl = Utilities.GenerateURL(url, login, date, key, customer);
account.Value.new_Link = generatedUrl;
if (!context.IsAttached(account.Value))
{
context.Attach(account.Value);
}
context.UpdateObject(account.Value);
}
SaveChangesResultCollection results = context.SaveChanges(SaveChangesOptions.ContinueOnError);
if (results != null)
{
foreach (SaveChangesResult result in results)
{
Type type = result.Request.GetType();
bool hasError = result.Error != null;
Entity entity = (Entity)result.Request.Parameters["Target"];
if (type == typeof(UpdateRequest))
{
if (hasError)
{
if (entity != null)
{
log.Error(result.Error.Message);
}
}
}
On my Dynamics entities, I have this :
[Microsoft.Xrm.Sdk.AttributeLogicalNameAttribute("new_link")]
public string new_Link
{
get
{
return this.GetAttributeValue<string>("new_link");
}
set
{
this.OnPropertyChanging("new_link");
this.SetAttributeValue("new_link", value);
this.OnPropertyChanged("new_link");
}
}
Right now, I got this error printed by the LogError :
The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://schemas.microsoft.com/xrm/2011/Contracts/Services:request. The InnerException message was 'Error in line 1 position 12271. Element 'http://schemas.datacontract.org/2004/07/System.Collections.Generic:value' contains data from a type that maps to the name 'http://schemas.microsoft.com/xrm/7.1/Contracts:ConcurrencyBehavior'. The deserializer has no knowledge of any type that maps to this name. Consider changing the implementation of the ResolveName method on your DataContractResolver to return a non-null value for name 'ConcurrencyBehavior' and namespace 'http://schemas.microsoft.com/xrm/7.1/Contracts'.'. Please see InnerException for more details.
After few searchs, I found 2 possible causes :
Enable Proxy type : the fact is I have the code to do that. So this couldn't help me.
_serviceProxy.EnableProxyTypes();
Version of SDK : I saw some answers about the fact that the SDK version 7.0 can cause this problem. The fact is that I am using the version 7.1 and I also try with the latest 7.1.1. I use this DLL's : Microsoft.Xrm.Client, Microsoft.Xrm.Sdk, Microsoft.Crm.Sdk.Proxy
Type of this element : I also try with a basic string as datatype. There is still problem of serealization.
None of these ideas solve my problem and right now, I do'nt really know where I am suppose to look into to solve fix this problem.
Also the problem might be unknown types. It's important to enable proxy types on OrganizationServiceProxy. It solved my issue with similar error
using (OrganizationServiceProxy proxy = new OrganizationServiceProxy(organizationUri, null, credentials, null))
{
proxy.EnableProxyTypes();
}
Not 100% what the issue is but I would suggest trying the following to see if it helps.
Regenerate your proxy, it might be a case that your proxy is out of date which is why the deserializer has no knowledge of any type that maps to this name.
Try using late bound just to see if that works, help to narrow things down if there is a problem in the early bound code. For example:
Entity account = new Entity("account");
account.Id = new Guid("");
account["new_link"] = "your value";
service.Update(account);
Break point the code and see what values are being updated on the account objects, e.g. make sure another attribute doesn't have an odd value.
I will share my solution to this problem, when using own created WCF services, which are using generated models from CRM.
When referencing the WCF service in other project using VS 2017, there are some options in the Add Service Reference window: press "Advanced..." and uncheck Reuse types in referenced assemblies
Hope it helps someone.
I have solved this problem by updating the referece Microsoft.Xrm.Tooling.Connector
It turned out that I was using an older version which did not match with others SDK references, but it did not crash when building the program.
You can use NuGet to get that assembly.
This is the project's URL:
https://learn.microsoft.com/es-es/dotnet/api/microsoft.xrm.tooling.connector?view=dynamics-xrmtooling-ce-9
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;
}
I'm following this OData V4 tutorial and now have a problem with the bound function MostExpensive.
This function is bound to the Productscollection and is registered in WebApiConfig.Register() like suggested in the tutorial:
ODataConventionModelBuilder builder = new ODataConventionModelBuilder();
builder.Namespace = "ProductService";
builder.EntityType<Product>().Collection.Function("MostExpensive").Returns<decimal>();
There is only described a rudimentary client for this service in part 2 of this tutorial. So I want to extend it so that I also can call the functions described in the later parts of the tutorial.
I have created the client using OData Client Code Generator as suggested in the tutorial. I then add some products and suppliers and then want to get the most expensive product:
static void Main(string[] args)
{
const string serviceUri = "http://localhost:52542";
Container container = new Container(new Uri(serviceUri));
AddProducts(container, GenerateSomeProducts());
AddSuppliers(container, GenerateSomeSuppliers());
Console.WriteLine("Most expensive product is: {0}", container.Products.MostExpensive().GetValue());
...
}
When calling GetValue() I am getting an InvalidOperationException stating that http://localhost:52542/$metadata refers to a Edm.Decimal type but a Collection(Edm-Decimal) type is expected.
When calling http://localhost:52542/Products/ProductService.MostExpensive() directly in the browser I'm getting
{
"#odata.context":"http://localhost:52542/$metadata#Edm.Decimal","value":40000.95
}
Which seems to be correct.
Do I do anything wrong? I have no idea how to fix this. So any suggestions about that?
I guess you are using T4 2.2.0, right?
There is a bug in T4 2.2.0 which causes this issue. You can use the content in following link to replace your ttinclude file and regenerate your proxy to work around the issue.
https://raw.githubusercontent.com/LaylaLiu/odata.net/T4TempFix/src/CodeGen/ODataT4CodeGenerator.ttinclude
I've downloaded the latest SignalR code (as of 04/04/12) from GitHub as it now compiles with MonoDevelop so I can use it on OS X.
But while testing the new version with the SignalR.Sample example listed on the Getting Started page, it fails with the following error:
The name 'AspNetHost' does not exist in the current context
This occurs in StockTicker.cs here:
private static dynamic GetClients()
{
return AspNetHost.DependencyResolver.Resolve<IConnectionManager>().GetClients<StockTickerHub>();
}
Can anyone explain what has become of AspNetHost?
Suggestions on how to get the SignalR.Sample compiling would be very welcome.
I had the same problem and found that this was deprecated in SignalR 0.5. Here is an article detailing the changes.
Specific to your item, the change is from this:
public void PerformLongRunningHubOperation()
{
var clients = AspNetHost.DependencyResolver.Resolve<IConnectionManager>().GetClients<MyHub>();
clients.notify("Hello world");
}
To this in 0.5:
public void PerformLongRunningHubOperation()
{
IHubContext context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
context.Clients.notify("Hello world");
}
You're gonna need to read the code because the source isn't in sync with the docs. The docs are for the current release, not the actively developed.
Take a look at the asp.net sample to see the current API. It's not set in stone yet though.
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