We are developing workflows in WF4 way. When we use some custom classes we have to add them to knowntypes collection in each send/receive activity to avoid serialization exception. Is there any way we can use DataContractResolver feature which is a new dotnet 4 feature to avoid adding knowntypes ? Or any alternate solution if any one can suggest ?? Thanks.
Sure - check out the sample:
http://msdn.microsoft.com/en-us/library/dd807504.aspx
Related
Autofac provides the OnActivated() method, which provides the capability to run any action after constructing a registered type.
Is possible to use a similar method in MvvmCross? Do you have any ideas to provide the same functionality?
It usually pays to understand the fundamentals of Dependency Injection (DI) instead of relying on particular DI Container features. Ask yourself the question: If I didn't have a DI Container, then how would I solve my problem?
Ironically, it turns out that things are usually much simpler with Pure DI.
If you didn't have a DI Container, then how would you run an action after construction of an object?
The easiest solution is to provide a factory that creates and initialises the object. Assuming the same API and requirements as the Autofac documentation implies, you could do this:
public static Dependency2 CreateDependency2(ITestOutputHelper output, Dependency1 dependency)
{
var d2 = new Dependency2(ITestOutputHelper output, Dependency1 dependency);
d2.Initialize();
return d2;
}
If you still must use another DI Container, most of them enable you to register a factory like the above against the type. I don't know how MvvmCross works, but I'd be surprised if this wasn't possible. If it isn't, you can implement an Adapter over your actual dependency. The Adapter would take care of running the action on the adapted object.
FWIW, if an object isn't in a valid state before you've run some action on it, then encapsulation is broken. The fundamental characteristic of encapsulation is that objects protect their invariants so that they can never be in invalid states. If possible, consider a better API design.
Using Conduit, I would like to create a new project.
However, the Conduit documentation is rather cryptic, and the Transaction Types of 'project.edit' don't really give a clue on what transaction(s) are required/optional, to establish this.
I realize that there is a 'project.create' but is marked as to be deprecated.
Could any of you help me out here?
Basically if you don't specify an objectIdentifier, project.edit will create a new project. Probably the name is mandatory, I don't think that anything else is for projects.
As those of you working with Entity Framework Core may know, the current version does not have an implementation for CurrentValues.SetValues() for Entities. It looks like support for this will come in the next release v1.1 as this issue states. Until then, does anybody have a solution that works for updating entity entries?
For context, the SetValues function in the past entity framework takes an entity and updates it properties to the values of an entity passed as a parameter i.e.:
var updatedEntity = currentEntity.CurrentValues.SetValues(newValues);
_dbContext.SaveChanges();
I've found some implementations using PropertyInfo to make a generic update function but haven't found anything that looks to be a nice clean solution. Might just have to take what I can get though :)
p.s. I realize this function only worked for simple entities that don't have complex object graphs that would require updating other related entities. My use case is simple. It's just annoying to have to manually map properties right now.
EDIT: Now that EF Core v1.1.0 has been released, CurrentValues.SetValues() will work.
See the following code snippet
var currentEntity = dbSetEntity.Find(id);
_dbContext.Entry(currentEntity).CurrentValues.SetValues(newValues);
I'm using NHibernate to administer my entities, and to have lazy loading enabled I need to make my properties return an IList<>. Problem is that .NET throws an exception as it can't serialize an interface when I'm trying to pass the entity. This makes perfect sense.
What I need to know is how I can control which fields to serialize, and which not to? My best bet so far is to work around this problem by copying the contents of IList<> into a List<> before serializing the object, but to do that I need to tell .NET that I don't want the IList<> property serialized :)
Just wanted to let you guys know that I found the answer to be the
[System.Xml.Serialization.XmlIgnore] attribute :)
MSDN has an area on Serializing Objects, but what you want is Selective Serialization. So basically, you can mark any property you don't want serialized with the attribute, [NonSerialized]. There is an example in the second link.
Has anyone used ADO.NET Data Services as a data source for Adobe Flex applications? If so, any success stories or tragedies to avoid? If you did use it, how did you handle security?
I use WebORB for .NET to do Flex remoting and then use DLINQ on the server. One tricky thing about using LINQ with WebORB is that WebORB uses Reflection to automatically retrieve all the relationships of the object(s) you return to Flex. This causes severe time penalties as LINQ uses lazy loading to load relationships. To prevent this from happening, I do something like the following:
Override your DataContext's constructor and add the following code:
this.DeferredLoadingEnabled = false;
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Order>(q => q.Payments);
dlo.LoadWith<Order>(q => q.Customer);
this.LoadOptions = dlo;
This tells the DataContext to disable deferred loading of relationships and specifically instructs it to load just the relationships you want, without lazy loading. That way, WebORB isn't causing any lazy loading to happen through Reflection and the number of relationships being transferred to Flex is kept at a minimum.
Hope this helps you in some way. It's definitely one of those little "gotchas" when working with Flex/WebORB and LINQ.
Yes, we use Flex with .Net web services extensively.
Flex can't handle .Net DataSets, or indeed much by way of complex xml types. We found that it was best to keep to relatively simple xml output.
However, if you do that, it can handle .Net web service output fine:
<mx:WebService id="myDataService" showBusyCursor="true">
<mx:operation name="WebMethodName"
resultFormat="object"
result="functionFiredOnComplete();">
</mx:operation>
</mx:WebService>
public function load():void
{
myDataService.loadWSDL( "web method's wsdl" );
myDataService.WebMethodName.send( params );
}
public function functionFiredOnComplete():void
{
// get data
var myData:Object = myDataService.WebMethodName.lastResult;
...
He Asked about ADO.NET Data Services not web service
Flex can only do GET and POST
Flex doesn't understand HTTP Response messages
So in order to have Flex talk to ADO.NET data services you either have to;
1. use a proxy server, but you have to find or build one yourself
2. modify the incoming requests and use $method=MERGE and so on (same as proxy)
3. use another as3 httpService client, there are some opensource initiatives
Then you have to find out how to post data, and it cost a lot of time when you want to create a new record with JSON and specify a Id wich has a link to another table. This because you can't just update the integer, but instead you have to create a link string, it's feels not really easy.
So ofcourse it can be done, but out of the box you really have to make it yourself. I know that Flash Builder 4 will come with a REST import, this could speed up things, but hve no experience for that