How to fix Cygwin (make)

If you are using Eclipse on Windows, CDT and Cygwin you might see funny meaningful errors like:

make: *** target pattern contains no `%'.  Stop.    

make: *** multiple target patterns.  Stop.   

Some of them occur only after the second build, others pop up continuously.

This is most likely happening due to the fact that Cygwin make is broken with the current 3.81 release.

After wasting many hours I came to this announcement dating to 9 Jul 2006 related to make 3.81 from Christopher Faylor from Redhat on the Cygwin announce list:

Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make.  If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.

Wikipedia describes Cygwin  as:

"Unix-like environment and command-line interface for Microsoft Windows."

In other this means that the make for Windows lacks Windows support.


This raises the following question:

Which user of  the Unix-like environment and command-line interface for Microsoft Windows. would ever miss the support  for MS-DOS aka Windows path names in the 2 most important development tool besides gcc?

I hope Chris is not thinking about shipping the next Redhat distro with a make that does not support Unix style path names. I mean this is fast way to increase your number of "fans" on Facebook but............

At least he is not only breaking it but also pointing in the right direction:

See: http://mingw.org/ for details on downloading a version of make
which understands MS-DOS path names.  Please! direct any questions about
the MinGW version of make to the appropriate MinGW mailing list.

Here you can download a version of mingw make.

I installs by default to C:\MinGW\bin\mingw32-make.exe

Then I just copied it to my cygwin\bin directory. After doing the only reasonable thing with the cygwin make, in other words deleting it, I just renamed mingw32-make.exe to make.exe and since then everything builds fine.

Update:

Robert Walker also pointed out that he offers some packages for download that contain all the necessary fixes.I tried 3.82-1 and its just works fine. Thanks!

Visual Studio 2010 COM-Interface Bugfest

"EnvDTE is an assembly-wrapped COM library containing the objects and members for Visual Studio core automation."

But unfortunately the implementation the the VS 2010 RTM version the library is pretty much unusable. Some methods like EnvDTE.Project.Delete() are not even implemented.


Others like EnvDTE._Solution.Remove(Project project) have buggy implementations. Removing a project with _Solution.Remove(Project project) will work, but when you try to add the same project from a different location using the _Solution.AddFromFile method you will end up with the error message "A project with that name is already opened in the solution". Once you removed it you have to restart Visual Studio if you ever want to be able to add the project to the solution.

As we speak the Visual Studio 2010 automation COM-Interface is not usable.

Workflow 4 Bugfest - no compensations

According to msdn

"Compensation in Windows Workflow Foundation (WF) is the mechanism by which previously completed work can be undone or compensated (following the logic defined by the application) when a subsequent failure occurs. This section describes how to use compensation in workflows."

Ok. Lets start with this very simple example:


But when you execute it you will find that...

Pufffff, it's gone!

None of our handlers is ever called. Our transaction is down the drain.

Hmm, maybe the transaction was not successful and this is the reason why none of handlers got called.

Lets try this:

But when you execute it you will find that...

the last message is "Do Transaction" then

Pufffffs, it's gone.

But on the other hand what happens if we delete the throw?

Then we see that the confirmed handler gets called at the end of our workflow.

This means:

If we use CompensableActivity and everything in our workflow completes successfully, the transaction gets "autocommitted". Otherwise its puffff gone.

But this behavior can be changed from outside.

Lets wrap the first example into one of this mysterious Try/Catch Block and let him handle the exception.



What we now see that all of a sudden our CancellationHandler gets called.

I am confused now.

First thing is that I would never expect my Compensation to just puffff. I mean I do serious thing in a compensation. This makes especially no sense to me, if a successful Compensation auto-commits and the end of the workflow. An even less if failed compensation calls the cancellationhadler only if it is wrapped into a Try/Catch block that handles the exception.

Update: In the MSDN Forum Steve Danielson investigated the issue and gave an excellent hint on the difference between C# Try/Catch and Workflow Try/Catch. This covers the behavior for CompensableAction as well

Workflow 4 Bugfest - The Exception handling bug

I currently dig into Workflow 4 (Final). After Workflow 3 really drove me nuts with its unbearable performance I was first positively impressed by Workflow 4. The designer as well as the workflow execution speed is there where I expect it to be.
I downloaded the samples and went through the basic shapes section. All fine here.

But my impression is about to change, as Workflow 4 seems to contain a number of serious bugs.

This becomes very evident if you look at the execution of the finally block in a try/catch activity.

According to msdn...

"The finally block is useful for cleaning up any resources allocated in the try block as well as running any code that must execute even if there is an exception. Control is always passed to the finally block regardless of how the try block exits."

The most simple form of a try-Catch Activity is this:

Please note that there is no Exception handler in the "Catches" section. I simply want the Exception to propagate, but before it does that I want to make sure my code block in finally is executed no matter what happens.

But if you now execute the code, you will find out that the code in our finally block never gets executed....

This will not change if you add an exception handler, that does not handle the specific exception.

To make things worse we will see, that even if we handle the specific exception and and want to rethrow it, our finally is never executed.

Actually the only time the finally gets executed in case of an exception is when the Exception is handled and not propagated.

This means:

In Workflow 4 you cannot propagate an exception and execute a finally block.

In other words:

You cannot use a finally block.

Update: In the MSDN Forum Steve Danielson gave an excellent hint on the difference between C# Try/Catch and Workflow Try/Catch.

The WCF Data Services Toolkit mess

Related to custom data providers for WCF Data Services I am just looking at the Data Service Provider toolkit and I notice several things.

1.) You obviously need tons of glue code to expose the most simple classes like.

public Class B
{
public string NoIdProperty {get;set;}
}

public Class A
{
public B MyB { get;set; }
public int MyIDProperty { get; set; }
}

2.) The whole System.Data.Services.Providers Namespace is as good as undocumented. At what point in time/in which order the fuctions in IDataServiceQueryProvider are called? Only reverse engineering or many breakpoints/stepping through will tell you.

3.) The whole namespace smells like entity framework to me (e.g. looking at the ResourceTypeKind enum).

4.) The whole data services error reporting/debugging is not even close to real life requirements. I definitely need more details that just "Something blew up somewhere". I need something like the WCF tracing facilities before I can ever think about getting a Data Service into a production environment.

5.) The toolkit code is a mess.
I only looked at the RO examples, but just looking at the typed and untyped examples you find many differences in the glue code. They do really questionable things like storing their own ResourceTypeAnnotions types in the CustomState properties of the that is obviously needed to store a missing link from the ResourceTypeRessourceTypes to the RessourceSets.
They do really messy things like in GetQueryRootForResourceSet(ResourceSet) function (typed/ro example) that are all but intuitive.
They need a whole bunch of helper and extensions classes (glue), only to make your own interfaces somehow usable.

In short: the Custom Data Service Providers interface feels like it was not designed for what we are trying to do here.

I really love the idea of WCF Data Services that expose objects, because they close a significant gap in current data access architecture.

Maybe I did not get the concept of custom data service providers or I am just too stupid, but so far it looks the current ADO .NET Data Service implementation will never match my expectations.

Maybe Microsoft should consider dumping the current implementation and start a rewrite that is designed for exposing objects over WCF, instead of just entity framework over HTTP. Trying to fix the current code seems to be a big waste of their and my time. But at least Microsoft should do their homework in regards to documentation before thinking about extensions.

How many clicks I need to delete a file owned by "TrustedInstaller"

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

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.