If you have the problem with this crap Vista based Windows Server 2008 that you want to delete a file owned by "TrustedInstaller", how many clicks do you need?
1.) Right Click on the file
2.) Left Click on "Properties"
3.) Left Click "Security Tab"
4.) Left Click "Advanced" Button
5.) Left Click "Owner" Tab
6.) Left Click "Edit" Button
7.) Left Click UAC "Continue" Button
8.) Left Click "Administrators"
9.) Left Click "OK" Button
10.) Left Click "OK" Button of Security Dialog
11.) Left Click "OK" Button
12.) Left Click "Edit" Button
13.) Left Click UAC "Continue" Button
14.) Left Click "Administrators" Button
15.) Left Click "Full Control" Checkbox
16.) Left Click "OK" Button
17.) Left Click "OK" Button
18.) Right Click "File"
19.) Left Click "Delete"
20.) Left Click "Continue" Button
21.) Left Click UAC "Continue" Button
And you need to do this for every single file.
Are you fucking kidding me?
Thanks god there are a few commandline utilities that do the job just as expected:
start an elevated "cmd"
Use:
takeown /f <FileOrDirectory> /r /a
icacls <FileOrDirectory> /grant administrators:F /t
Wednesday, February 24, 2010
Tuesday, February 16, 2010
XSD to NHibernate-WCF contract converter
Guess you want to generate a WCF Data Contract from an XSD. In this case you use svcutil with /dconly option. This tool is based on
XsdDataContractImporter, so it can convert XSD files the same way, as svcutil does it.
But what do you do if you want to persist your object with NHibernate? You cannot do this with the contract generated from svcutil. The core of the problem is, that though you can switch the collection type with the /ct: options to IList. the generated data contract will not build. Second issue is that all the properties are generated public but not virtual public as we need this for NHibernate.
As svcutil is basically a wrapper around framework classes, I slapped together a small custom XSD to Class converter that generates classes that can be directly filled with NHibernate. All the customization is encapsulated in xsdconverter.cs. So feel free to change the frontend (WPF here) to whatever you like.
90% of the code is dedicated to another feature of the generator. It is capable of generating code comments from your<xs:annotations> elements. This code is based on the code released by Xsd2Code project.
You can get it here.
Due to some unlucky limitations of System.Runtime.Serialization (see comments) using the NHibernate option the serialized object may not be valid against the schema. As long as you do not require valid XML against your schema (and you probably won't) this restriction does not matter though.
XsdDataContractImporter, so it can convert XSD files the same way, as svcutil does it.
But what do you do if you want to persist your object with NHibernate? You cannot do this with the contract generated from svcutil. The core of the problem is, that though you can switch the collection type with the /ct: options to IList. the generated data contract will not build. Second issue is that all the properties are generated public but not virtual public as we need this for NHibernate.
As svcutil is basically a wrapper around framework classes, I slapped together a small custom XSD to Class converter that generates classes that can be directly filled with NHibernate. All the customization is encapsulated in xsdconverter.cs. So feel free to change the frontend (WPF here) to whatever you like.
90% of the code is dedicated to another feature of the generator. It is capable of generating code comments from your
You can get it here.
Due to some unlucky limitations of System.Runtime.Serialization (see comments) using the NHibernate option the serialized object may not be valid against the schema. As long as you do not require valid XML against your schema (and you probably won't) this restriction does not matter though.
Monday, February 15, 2010
Enjoy the WCF Data Services sandwich
For 60 years in IT, there are lot of the ever repeating questions in every project.
Among them:
How do I load/persist my object in my relational database?
Who hopes Microsoft is finally giving the the answer with Entity Framework 4 will be disappointed. EF 4 is nailed on my SQL-Server relational tables. But what's a data-access layer worth that exports relational tables? Well, it's simply not what I call a data-access layer. It is a relational table presentation layer, but nothing more. For me a good data-access layer returns at least data transfer objects, that totally abstract the physical storage. Given that fact that I don't like the idea of stacking up a table presentation layer with my own projection framework, EF4 can't be part of any serious architecture I use.
But what about WCF Data Services?
Among the ever returning questions in IT there is also the following question.
How can I forward the query from my client to my object repository if I want it to?
The problem with DDD repositories, is that you basically need the exact number of functions as the number of query possibilities you want to have.
Following example:
public class A
{
public string PropA { get;set; };
public string PropB { get;set; };
public string PropC { get;set; };
}
How many operations you want to implement until you get the flexibility you need?
Maybe
GetAByPropA(string particle);
GetAByPropB(string particle);
GetAByPropC(string particle);
GetAByPropAorB(string particle,string particleB);
GetAByPropAandB(string particle, string particle);
GetAByPropAorC(string particle, string particleB);
Of course you would not implement
GetAByPropAorB(string particle,string particleB);
but maybe
GetAByQuery(List<string>, List<Operator>)
But what are the Operators....
You have 2 options now.
1.) You accept that you cannot implement all the operations you basically need. That means to accept the gap. That means you need to do client side filtering. That means your data-access layer puts much more load on the whole system than necessary
2.) you find yourself writing your own query language.
So either I take the ugly 90% solution or I waste my project time writing a query language instead of implementing business cases. From my point of view this sounds like the choice between black death and cholera. Basically this is the moment to realize we have just broken through the ceiling of current SOA patterns.
But wait. Microsoft promises me they have the answer. It's called WCF Data Services!
What are WCF Data Services related to classic WCF services?
In classic WCF you expose operations. In WCF Data Services you expose objects. WCF Data Services come with a built in functionality to perform queries on a collection of objects exposed through the service.
In .Net terms this means, I can perform a Linq query on the collection of my client proxy object. The client serializes my query through OData protocol, which is then deserialized on the server to a Linq expression again. And with my Linq expression I can basically forward the query directly to my data store. This means I retrieve only the exact data requested and return just the amount of data necessary.
Awesome! All I do is to expose my object, and this is it! Bye 100 insuffient operations, bye you hateful custom query language.
I watched the videos, everything looks absolutely idiot proof. Lets try it.
I tried it on .Net 3.5 getting the latest update, as well on .Net 4 with Visual Studio 2010 RC.
But as I do not like Entity Framework I used my really simply WCF contract. I exposed it through my Data Service and....
"Request Error. The server encountered an error processing the request. See server logs for more details."
Who knows where there is the log for the ASP.Net development server?
To save you the same amount of frustration I recommend you slap the following attribute on your DataService class.
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
In .Net 3.5 the error message you now get is even less on the first glance.
If you get meaningful exceptions like
System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke ....
this probably means the same as the the error message:
"MyType is not entity type"
? What does that mean?
With WCF Data Services you just cannot expose WCF data contracts. Basically WCF Data Services are missing WCF compatibility. Well.....
You can only expose objects that have either:
a public set & gettable property: ID (yes, case sensitive)
or
a public set & gettable property: <classname>ID
or are decorated with the
[DataServiceKeyAttribute]
What does that mean?
public class MyClass
{
public string Name { get; set;}
}
Not working. And be careful with just slapping [DataServiceKeyAttribute("Name")] on your class. As Name is not a unique identifier of your class you may see some unexpected results if you query provider return 2 objects with the same name. Make sure you test this choice.
public enum myEnum
{
one,
two
}
public class MyClass
{
public string ID { get; set;}
public myEnum MyEnum { get; set;}
}
not working
public class MyOtherClass
{
public string Name { get; set;}
}
public class MyClass
{
public string ID { get; set;}
public MyOtherClass MyOtherClass { get; set;}
}
not working as B has no unique identifier on its own.
It looks like we have to approach the question from the other side. So what is working?
Well, basically if you want to transport your own classes not much. If you have no access to source of the class basically nothing. But I have my WCF data contracts! What happened?
If you look the Microsoft Pod casts on the subject you see that most their examples are based on the Entity Framework. And if you look closer you find all the limitations in Entity Framework currently are found in Data Services as well. In other words Entity Framework are perfect partners. But this in fact means that both technologies are quite tightly coupled. This makes sense if you consider that WCF Data Services were called ADO.Net Data Services before. The original design was obviously not for exposing object but database entities. For me it feels the whole concept was originally intended to give Silverlight developers access to a remote SQL-Server database because Silverlight runs in sand boxed context of the browser behind a firewall.
But in fact this is what you get.
So what basically happened is that they nailed the Data Services on Entity Framework which is nailed on relational SQL Server tables. In short: WCF Data Services are intended to provide a web based access to relational SQL server tables.
Now you tell me something about decoupled architecture..... Basically amazing how you manage to nail not only some software components but 3 complete technology frameworks together.
If you try to expose your object or only your WCF data contract through WCF Data Services, you probably will not recognize your object anymore when your implementation finally suffices WCF Data Services.
At the end the result is more than disappointing. If you do not like the SQL-Server, Entity Framework, Data Services Sandwich you can put this technologies aside and wait for Microsoft to publish something more generally usable. Maybe some when somewhere on CodePlex?
More and more it seems the whole .Net 4 release seems to be full set of half ready technologies. WF4 is missing State Machines, the ORM Entity Framework 4 is missing (o)bjects and (m)appings, WCF Data Services are missing WCF, industry standards like XSLT 2 are completely missing. Maybe it's time for Microsoft to rename .Net 4 to .Net 3.75. For me it looks like it looks like Microsoft lost sight in the Cloud.
Please correct me if I got something completely wrong. I am more than happy to correct my findings. Please use the comment function for this.
Update: With the move from ADO.Net Data Services to WCF Data Services Microsoft obviously realized that the current implementation does currently not fulfill the expectations implied by the term WCF.
That is why they come up with a custom Data Service Provider Interface that allows you to plug in new models into WCF Data Services.
Among them:
How do I load/persist my object in my relational database?
Who hopes Microsoft is finally giving the the answer with Entity Framework 4 will be disappointed. EF 4 is nailed on my SQL-Server relational tables. But what's a data-access layer worth that exports relational tables? Well, it's simply not what I call a data-access layer. It is a relational table presentation layer, but nothing more. For me a good data-access layer returns at least data transfer objects, that totally abstract the physical storage. Given that fact that I don't like the idea of stacking up a table presentation layer with my own projection framework, EF4 can't be part of any serious architecture I use.
But what about WCF Data Services?
Among the ever returning questions in IT there is also the following question.
How can I forward the query from my client to my object repository if I want it to?
The problem with DDD repositories, is that you basically need the exact number of functions as the number of query possibilities you want to have.
Following example:
public class A
{
public string PropA { get;set; };
public string PropB { get;set; };
public string PropC { get;set; };
}
How many operations you want to implement until you get the flexibility you need?
Maybe
GetAByPropA(string particle);
GetAByPropB(string particle);
GetAByPropC(string particle);
GetAByPropAorB(string particle,string particleB);
GetAByPropAandB(string particle, string particle);
GetAByPropAorC(string particle, string particleB);
Of course you would not implement
GetAByPropAorB(string particle,string particleB);
but maybe
GetAByQuery(List<string>, List<Operator>)
But what are the Operators....
You have 2 options now.
1.) You accept that you cannot implement all the operations you basically need. That means to accept the gap. That means you need to do client side filtering. That means your data-access layer puts much more load on the whole system than necessary
2.) you find yourself writing your own query language.
So either I take the ugly 90% solution or I waste my project time writing a query language instead of implementing business cases. From my point of view this sounds like the choice between black death and cholera. Basically this is the moment to realize we have just broken through the ceiling of current SOA patterns.
But wait. Microsoft promises me they have the answer. It's called WCF Data Services!
What are WCF Data Services related to classic WCF services?
In classic WCF you expose operations. In WCF Data Services you expose objects. WCF Data Services come with a built in functionality to perform queries on a collection of objects exposed through the service.
In .Net terms this means, I can perform a Linq query on the collection of my client proxy object. The client serializes my query through OData protocol, which is then deserialized on the server to a Linq expression again. And with my Linq expression I can basically forward the query directly to my data store. This means I retrieve only the exact data requested and return just the amount of data necessary.
Awesome! All I do is to expose my object, and this is it! Bye 100 insuffient operations, bye you hateful custom query language.
I watched the videos, everything looks absolutely idiot proof. Lets try it.
I tried it on .Net 3.5 getting the latest update, as well on .Net 4 with Visual Studio 2010 RC.
But as I do not like Entity Framework I used my really simply WCF contract. I exposed it through my Data Service and....
"Request Error. The server encountered an error processing the request. See server logs for more details."
Who knows where there is the log for the ASP.Net development server?
To save you the same amount of frustration I recommend you slap the following attribute on your DataService
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
In .Net 3.5 the error message you now get is even less on the first glance.
"The XML page cannot be displayed"
To save you some more frustration I recommend to use FireFox as your default browser. In case of invalid XML IE simply does let you view the source of the document. Although FireFox comes up with a similar "XML processing error" message, you can at least always show the source of the page and sometimes this will get you to the source of the problem.If you get meaningful exceptions like
System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke ....
this probably means the same as the the error message:
"MyType is not entity type"
? What does that mean?
With WCF Data Services you just cannot expose WCF data contracts. Basically WCF Data Services are missing WCF compatibility. Well.....
You can only expose objects that have either:
a public set & gettable property: ID (yes, case sensitive)
or
a public set & gettable property: <classname>ID
or are decorated with the
[DataServiceKeyAttribute]
What does that mean?
public class MyClass
{
public string Name { get; set;}
}
Not working. And be careful with just slapping [DataServiceKeyAttribute("Name")] on your class. As Name is not a unique identifier of your class you may see some unexpected results if you query provider return 2 objects with the same name. Make sure you test this choice.
public enum myEnum
{
one,
two
}
public class MyClass
{
public string ID { get; set;}
public myEnum MyEnum { get; set;}
}
not working
public class MyOtherClass
{
public string Name { get; set;}
}
public class MyClass
{
public string ID { get; set;}
public MyOtherClass MyOtherClass { get; set;}
}
not working as B has no unique identifier on its own.
It looks like we have to approach the question from the other side. So what is working?
Well, basically if you want to transport your own classes not much. If you have no access to source of the class basically nothing. But I have my WCF data contracts! What happened?
If you look the Microsoft Pod casts on the subject you see that most their examples are based on the Entity Framework. And if you look closer you find all the limitations in Entity Framework currently are found in Data Services as well. In other words Entity Framework are perfect partners. But this in fact means that both technologies are quite tightly coupled. This makes sense if you consider that WCF Data Services were called ADO.Net Data Services before. The original design was obviously not for exposing object but database entities. For me it feels the
But in fact this is what you get.
So what basically happened is that they nailed the Data Services on Entity Framework which is nailed on relational SQL Server tables. In short: WCF Data Services are intended to provide a web based access to relational SQL server tables.
Now you tell me something about decoupled architecture..... Basically amazing how you manage to nail not only some software components but 3 complete technology frameworks together.
If you try to expose your object or only your WCF data contract through WCF Data Services, you probably will not recognize your object anymore when your implementation finally suffices WCF Data Services.
At the end the result is more than disappointing. If you do not like the SQL-Server, Entity Framework, Data Services Sandwich you can put this technologies aside and wait for Microsoft to publish something more generally usable. Maybe some when somewhere on CodePlex?
More and more it seems the whole .Net 4 release seems to be full set of half ready technologies. WF4 is missing State Machines, the ORM Entity Framework 4 is missing (o)bjects and (m)appings, WCF Data Services are missing WCF, industry standards like XSLT 2 are completely missing. Maybe it's time for Microsoft to rename .Net 4 to .Net 3.75. For me it looks like it looks like Microsoft lost sight in the Cloud.
Please correct me if I got something completely wrong. I am more than happy to correct my findings. Please use the comment function for this.
Update: With the move from ADO.Net Data Services to WCF Data Services Microsoft obviously realized that the current implementation does currently not fulfill the expectations implied by the term WCF.
That is why they come up with a custom Data Service Provider Interface that allows you to plug in new models into WCF Data Services.
Entity Framework 4 - The light of .Net ORM dawn?
For 60 years in IT, there are lot of the ever repeating questions in every project.
Among them:
In what format I do send my data to the consuming system?
Well, finally we solved this.... That's XML. Checked.
How do I get my data to the consuming system?
Well, that's WCF for all .NET folks. Checked.
How do I load/persist my object in my relational database?
Well, hmm, uhhh.
I promise the number of different relational data access/persistence implementations in .Net are only little lower than the number of .Net apps running on this planet using that technology. How we do data-access is a question of the style of each developer and thus dependent on the person not the technology. This of course is additional risk to every .Net project at a quite low level.
Compared to Java, in the area of ORM .NET seems to be light years behind. What Microsoft shipped as Entity-Framework 1.0 was as good as the WF-WCF 3 integration or in other words.... simply beyond every comment. But with is the upcoming .Net 4 ships the new Entity-Framework 4. So is there finally the light of dawn coming into the .Net ORM world?
I tried it and the result was bringing me back to earth quickly. Guess you have
class B
{
public string Id { get;set }
}
class A
{
public string Name { get;set }
public List<B> Bs { get;set;
}
and you want to map this to a database you find out that...
you cannot do that with the standard approach of Entity-Framework 4. Here you can only move a property from entity A to B if there is a 1 : 1 relationship between those tables.
Out of the box EF4 is just a lazyload DataSet 2.0 with autogenerated query,update, insert commands. But it is nailed on my relational tables. The other problem I see here is that out of the box EF4 currently supports SQL-Server only. If you want other database support you need 3rd-party provider.
From an architecture point of view this is good enough for "Click and Shoot" applications, but not for serious applications that require abstraction of the data from the underlying storage.
If you want to use EF4 in this scenarios, you need to switch to POCO mode. It looks like you have to sacrifice most of the the tools and code generation support though. There are some POCO templates for code generation, but if I look at the known defects list, this whole thing does not look quite production ready. It looks like the EF evolution from DataSet 2.0 to an serious ORM tool is ongoing, but I would not make a bet it happens with this release. So hopefully with EF 5 we can expect some more mature solution here.
Meanwhile related to true ORM instead in the light of dawn we have to walk in utter darkness?
No.
I looked into NHibernate lately and although it does not completely meet my (too high?) expectations of an *Object* Relational Mapper, you can do a lot more things with it than you can do with EF4. It really feels like a mature ORM framework to me.
So I cannot map the exact above example but at least I can map what gets me at least to the same usability I intended.
class B
{
public virtual string Id { get;set }}
}
class A
{
public virtual string Name { get;set }
public virtual IList<B> Bs { get;set; }
}
This is pretty much a basic problem for NHibernate. But you can solve a lot more problems with it, like inheritance, cyclic references, Write/Read batching (in other words performance tuning),it supports lazy load with different proxies...
There is a (not quite impartial) comparison of Entity Framework 4 vs NHibernate. The comparison ends with the pro's of EF4 being "A better Linq provider and it's from Microsoft".
The downside of NH is of course, that is not just "Import tables" click and shoot. As you have some choice on the mappings you have more complexity and more handwriting and configuration.
Maybe I have to give up my idea of *the* ORM. It seems you have to forget about the "O". The best that can be done is an "E" or "Entity" Relational Mapper, where "Entity" is a technology related subset of "Object". And the the bigger your subset is the better is your ERM tool.
Among them:
In what format I do send my data to the consuming system?
Well, finally we solved this.... That's XML. Checked.
How do I get my data to the consuming system?
Well, that's WCF for all .NET folks. Checked.
How do I load/persist my object in my relational database?
Well, hmm, uhhh.
I promise the number of different relational data access/persistence implementations in .Net are only little lower than the number of .Net apps running on this planet using that technology. How we do data-access is a question of the style of each developer and thus dependent on the person not the technology. This of course is additional risk to every .Net project at a quite low level.
Compared to Java, in the area of ORM .NET seems to be light years behind. What Microsoft shipped as Entity-Framework 1.0 was as good as the WF-WCF 3 integration or in other words.... simply beyond every comment. But with is the upcoming .Net 4 ships the new Entity-Framework 4. So is there finally the light of dawn coming into the .Net ORM world?
I tried it and the result was bringing me back to earth quickly. Guess you have
class B
{
public string Id { get;set }
}
class A
{
public string Name { get;set }
public List<B> Bs { get;set;
}
and you want to map this to a database you find out that...
you cannot do that with the standard approach of Entity-Framework 4. Here you can only move a property from entity A to B if there is a 1 : 1 relationship between those tables.
Out of the box EF4 is just a lazyload DataSet 2.0 with autogenerated query,update, insert commands. But it is nailed on my relational tables. The other problem I see here is that out of the box EF4 currently supports SQL-Server only. If you want other database support you need 3rd-party provider.
From an architecture point of view this is good enough for "Click and Shoot" applications, but not for serious applications that require abstraction of the data from the underlying storage.
If you want to use EF4 in this scenarios, you need to switch to POCO mode. It looks like you have to sacrifice most of the the tools and code generation support though. There are some POCO templates for code generation, but if I look at the known defects list, this whole thing does not look quite production ready. It looks like the EF evolution from DataSet 2.0 to an serious ORM tool is ongoing, but I would not make a bet it happens with this release. So hopefully with EF 5 we can expect some more mature solution here.
Meanwhile related to true ORM instead in the light of dawn we have to walk in utter darkness?
No.
I looked into NHibernate lately and although it does not completely meet my (too high?) expectations of an *Object* Relational Mapper, you can do a lot more things with it than you can do with EF4. It really feels like a mature ORM framework to me.
So I cannot map the exact above example but at least I can map what gets me at least to the same usability I intended.
class B
{
public virtual string Id { get;set }}
}
class A
{
public virtual string Name { get;set }
public virtual IList<B> Bs { get;set; }
}
This is pretty much a basic problem for NHibernate. But you can solve a lot more problems with it, like inheritance, cyclic references, Write/Read batching (in other words performance tuning),it supports lazy load with different proxies...
There is a (not quite impartial) comparison of Entity Framework 4 vs NHibernate. The comparison ends with the pro's of EF4 being "A better Linq provider and it's from Microsoft".
The downside of NH is of course, that is not just "Import tables" click and shoot. As you have some choice on the mappings you have more complexity and more handwriting and configuration.
Maybe I have to give up my idea of *the* ORM. It seems you have to forget about the "O". The best that can be done is an "E" or "Entity" Relational Mapper, where "Entity" is a technology related subset of "Object". And the the bigger your subset is the better is your ERM tool.
Subscribe to:
Posts (Atom)