Hello everyone!

I have the following project setup: MyGame, MyLibrary, MyLibrary.Content.Pipeline.
Both MyGame and MyLibrary has their own Content subprojects, with MyLibrary having some shared shaders.
MyGame has references set to both MyLibrary and MyLibrary.Content.Pipeline and the Content from MyLibrary gets copied automatically to the output directory of MyGame (via the references).

So far so good. Now over to the MyLibrary.Content.Pipeline - in there I have this modelprocessor (which I set on the models in MyGame) - it basically sets the correct shader on a model via an ExternalReference<>. This works fine if the shader is also added to the Content project of MyGame - but as you probably already have guessed I want to refer to a shader from within MyLibrary and not have to include it manually in every new game using MyLibrary. The problem is that the shader .fx-file is not yet available in MyGame when the custom modelprocessor is running and the content pipeline complains that the file is missing.

Is there some way to make the referenced MyLibrary project output it's content to MyGame's output directory before MyGame's content is processed? Or maybe I should just give in and put everything in there manually (with links so source is shared)...?

Any input is welcome!

Cheers,
neo

Yes, there is -sort of. You should read these threads:

http://forums.xna.com/thread/53614.aspx

http://forums.xna.com/thread/55061.aspx

Hope it helps.

Thanks for those links - I don't remember finding those when I tried searching before...must have used some bad keywords! ;)
I'll give it a spin when I get home from work.


Cheers,
neo

Still can't get it to work. Probably just me who doesn't understand the Pipeline model yet - but it seems that no matter how a try - it all boils down to the fact that the shader code I'm trying to reference isn't there in the Content subproject of MyGame. The shader is available only after MyLibrary's Content subproject is built and the result is copied to MyGame's output directory - so I guess it'll never be available during the build of MyGame's Content.

This leads my to a followup question - How to you guys usually manage shared "library" content? Do you avoid it altogether by using linked assets, or do you have some uber-clever way of doing it? ;)

One way I can image doing it is by defer the loading of any shared content to run-time and don't do it during the compilation, only putting in strings with the asset's name - that way the content should be available when needed. But I'm not sure if this is a good way to go, or is it?

Cheers,
neo

I have the same problem. I don't find any related help in the links provided above though. What is needed, is a way to specify a project, in addition to the file path, when declaring an ExternalReference. I'm just going to make a script called before the game build which will copy the external contents of my library to the external contents of the game... if Windows was supporting real symbolic links, it would be easier to work around this problem also.

As you probably already know Visual Studio supports a kind of symbolic links, but if you don't here is how: Add existing files and instead of just clicking the Add-button (or is it OK), pull down the little menu behind it and choose "add as link". You'd have one copy, but still need to set up two references/links - so I guess a copy script is easier. :)

I've decided to go with asset names only so far, and then load/set references in runtime. I figure it will work fine if a ever build an editor...I also have looked some into embedding the shared/library content into MyLibrary, so an assembly reference is enough and no project reference is needed. It should be fine since it's a couple of simple shaders, a spritefont, and some small textures. Haven't gotten around to actually implement it yet though.

BTW for embedded shaders I just tried Brandon Bloom's EffectGenerator and after some minor tweaks it seems to work just fine and as a plus gives typed access to all parameters! I might go with that one, guess I have to decide which way works best at some point... ;)