Visual Studio project templates offer two ways of specifying template parameter values:
- In the .vstemplate file, using a CustomParameters section, as described here.
- Using a template wizard in order to specify run-time values in the IWizard.RunStarted method, as described here.
The problem is that these mechanisms don’t work as one would expect in the case of multi-project templates. The parameters specified in the root template are not picked up by the child project templates. I tried to find a workaround online but could not find anything. Finally, I came up with a workaround of my own.
In the previous parts of this articles I’ve talked about the service components of the XNA Streaming system. In this part, I’m going to talk about the Communication Broker.
The role of the Communication Broker is to cover the communication with the Streaming Service. By doing so, the code required of client applications is simplified, and less duplicate code will be generated for each application using the system. the broker also caches all variable changes and periodically sends all changes accumulated to the service, thus reducing the number of calls per second required by a single client to a predictable amount.
After quite a long break, I resume the series of articles on my XNA Streaming project by describing the actual Stream Service component. This component is responsible for transmitting the broadcast information to all connected users.
The information is encoded in (<property name>, <value>) pairs. All serializable data types are supported for values. Users register with the Stream Service either as Broadcaster or as Observer. After this step, the Broadcaster uses the service to send updates for information (property-value pairs). Observers get notified by the service of the updated information via a IXNAStreamCallback callback contract, a feature of WCF services.
In part one of this article, I did an overview of the XNA Streaming project. In this part I’m going to describe the File Transfer Service.
The main responsibility of the File Transfer Service is to provide access to streamable games. The service stores the game files in a database table, together with their relative file paths. This way the file system structure can be recreated when downloading the game. The game’s name, author and a short description are also stored in another table.
As I mentioned in my previous post, at this year's Microsoft Community Bootcamp I entered in the demo competition together with Adi. We've had some issues in the past with (cheap) broadcasting of presentations. There are plenty of professional tools out there that accomplish this goal, but that's not my point. My point is that I have not yet found a cheap (free) utility that will allow me to give a presentation to several viewers that may not be in the same room (or the screen isn't big enough for the whole audience).
Given this background, Adi proposed we create a way in which several people can see the same thing that a broadcaster transmits. Further, the "thing" that everyone sees is actually an XNA game, that could might as well be an interactive presentation in 3D.
During 11.09.2008 and 14.09.2008 I attended the fifth annual event dedicated to Microsoft professionals from the industry and academic environment. I also attended last year and wrote a bit about the experience here. A change from last year's event was the fact that this year, the professionals invited were almost as many as MSPs (until now, only a handful of MVPs had been invited). The location was Vatra Dornei. Possibly due to the fact that the bootcamp was held later than last year, it was much colder (and so we were "encouraged" to stay indoors or dress "heavily").