In Visual Studio, can I make one file run another's custom tool? (in this case using Xsd2Code)

Question

I am trying to work out if it is possible, when using a Custom Tool in Visual Studio, to have a change in the contents of one file, trigger the Custom Tool of another.

My scenario is this:

In a Visual Studio C# project, I have an "master.xsd" xml schema which includes several other other xsd files. I am using the Xsd2Code Visual Studio Custom Tool to generate a .cs from the schema. This works fine when the master.xsd itself changes, but I would like the custom tool to run on the file master.xsd when one of the other xsds changes.

Is there any way of one file triggering another's Custom Tool?

[EDIT - more detail on why I'm looking into using a custom tool for this]

At present we have a GenerateFiles.bat file that calls Xsd2Code from the command line to generate the code fiels from the schemas (as suggested by MattDavey below). This works, is just too slow.

The problem is that on every build Xsd2Code will, run but because lots of other projects depend on this project with the schemas, they will all recompile too even though probably nothing has changed. The practical upshot is that even a minor change to a unit test involves half the projects recompiling. This is why we've been looking at the custom tool approach to only generate the code files if the schema changes.

Blocky

Answer 1

I use Xsd2Code a lot in this way, but my approach is to add a pre-build event which calls the Xsd2Code command line and regenerates the xml on each build..

My pre-build event looks like this:

$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs /platform Net40 /collection Array  /sc+ /ap+ /if- /xa+

In your case you could run this pre-build step only on the master xsd (which i'm guessing xsd:Imports the other schemas), or you could run the command on each of your schema files individually.

The advantage for this is that, if I change the XSD schema, I get very useful compile time errors :)

Hope that gives you some ideas!

EDIT

I spent some time thinking about the issue you highlighted regarding build time and modified the pre-build script like so:

$(ProjectDir)BuildTools\Xsd2Code.exe $(ProjectDir)Api\Schemas\MySchema.xsd MyProject.Api.Schemas $(ProjectDir)Api\Schemas\MySchema.cs.temp /platform Net40 /collection Array  /sc+ /ap+ /if- /xa+

fc $(ProjectDir)Api\Schemas\MySchema.cs  $(ProjectDir)Api\Schemas\MySchema.cs.temp

if errorlevel 1 copy $(ProjectDir)Api\Schemas\MySchema.cs.temp $(ProjectDir)Api\Schemas\MySchema.cs /Y

del $(ProjectDir)Api\Schemas\MySchema.cs.temp

So Xsd2Code is now generating the source code into a temporary file, which is only overwriting the existing .cs file if it is different. This should mean that if the .xsd hasn't changed at all, neither will the generated .cs :)

You're still taking the hit of running xsd2code, but you're not taking the hit of msbuild rebuilding an entire chain of projects if the generated source was the same..

Skylight

Thanks for the suggestion. Unfortunately, this is the way we do it at the moment, and it is just too slow. The problem is that on every build Xsd2Code will, run but because lots of other projects depend on this project with the schemas, they will all recompile too even though probably nothing has changed. This is why I've been looking at the custom tool approach to only generate the code files if the schema changes. In other scenarios though, I think the approach you detail is a good one. – Blocky

ooh tough one. First thing that comes to mind is skipping the xsd2code step when the xsd file is unchanged. This might involve a slightly more complex pre-build batch script, possibly generating a hash of the xsd file and comparing it to a previously stored hash. But I'm just speculating now :) – Skylight

Thanks Matt - Nice idea - I hadn't thought of that. It may well do the job - xsd2code itself is fairly fast; it was just the chain of projects that was slowing things down I think. I shall give it a go and see. – Blocky

Haven't tried yet - but hope to before too long. I suspect it will work to be honest. I'll see if I can give it a go later this week. – Blocky