I promised a while ago to publish a roadmap for what we're doing with DSL Tools, post VS2008. Now that VS2008 and the VS2008 SDK have just shipped (thanks Gareth for providing a post which points at both announecements) now seems a good time honour that promise.
There are two main themes in how we expect DSL Tools to develop in the future:
I mentioned the second theme soon after the DSL Tools team joined the Visual Studio platform team. That is still in our sights and will be part of our roadmap for the VS SDK as a whole, which we'll publicize when it's ready. For the remainder of this post, I’ll focus on the first theme.
Roadmap for VS codename Rosario
Below is a list of features we have in the backlog for Rosario. We’re not promising to complete all of them, but expect to complete a significant subset. Some of the features may appear earlier in a service pack for VS2008.
The two main investments we’re considering post-Rosario are:
Well, that's all for now. Please provide your feedback on this. What do you like? What don't you like? What's on your wish list?
Now Visual Studio 2008 is released (I know, I'm blogger #100.000 to mention this) it is interesting to
Thanks for this amazing (SDK) piece of software, the scope and possibilities are endless. Even without WPF and all the features you mention for the next release this SDK opens up a whole world.
I would like to have a generated-model without requiring Microsoft's assemblies.
As I am following a <a href="http://www.himalia.net/blogs/leovernazza/2007/11/models-runtime.html">runtime approach</a> for the end-user (not the dsl user, but the end user), I require the model assemblies not only in the dsl user machine but in the end-user one.
I don't want to be tied to the Microsoft policies with my end-user-runtime.. (can I distribute them?, does the user need VS?, etc.)
My approach so far, has been to create my own model, and use the dsl-generated-model as a bridge. It could be far better to automatically use your model... I can also rewrite the model-generation templates. This will be probably my next step...
Thanks for publishing the roadmap...
I’m sure you know that Visual Studio 2008 has shipped, but did you also know that the Visual Studio 2008
Stuart has blogged a roadmap of future plans for DSL Tools.
Buenas hace unos días Stuart Kent nos comentaba en su blog parte de las ideas que guían el Roadmap para
"Although it is possible to create a custom editor with a placeholder for you to write your own forms-based editing surface"
Are there any examples or guidiance on this? As this is the exact scenario I'm trying to investigate if DSL Tools is a valid solution for our problem.
I'd love to have the DSL designer in our client winforms app, without having to customize the VS Shell.
Stuart Kent has posted a roadmap for DSL Tools for VS Rosario and beyond. This one (post-Rosario, ie...
In response to BrentP:
There's an example of how to do this in our book, with sample code on the website www.domainspecificdevelopment.com
In the DSL Designer, you delete the editor node in the explorer, then add a new custom editor to replace it (note that you'll lose all your toolbox entries when you do this). When you regenerate and rebuild you'll find there is a build error with a comment in the generated code with instructions on the method you need to provide.
Note, however, that we only currently support the scenario where the designer is hosted in a VS shell, including the new customizable, and freely distributable VS2008 shell.
This is a development roadmap for the DSL Tools published by Stuart Kent: DSL Tools Beyond VS2008
Your DSL tools are just purely amazing work.
I made my so-called "AppBuilder" in two months, thanks to them.
I did addressed my own way the orchestrated code generation issue.
In a few words, here's my approach :
* I have an XML config file hosted in a special, fixed-name project of the solution (arbitrarily named "App.Model", but that's held in a registry key, if you don't like this name) which describes commands ("generate the UI, generate the SQL, etc")
* the VS designer (or, rather, the DslPackage) for my DSL implements a context menu which brings up a dialog box (coded once for all) proposing the XML-ized commands in a drop down
* when you select a command in the drop down, the dialog box dynamically compiles a small C# script (also hosted in "App.Model" special project, in a "scripting" folder) and instantiate an object implementing my IScriptedCommandHandler interface (where only one method is surfaced : Execute(...))
* the DslPackage / VS designer for my DSL passes the context (current model element selection and current opened EnvDTE solution in VS) to the scripted interface, allowing it to populate or augment the solution with projects and/or source files generated by the DSL template engine that I call thanks to a technique describe in the DSL tools forums.
I'm rather happy with this : I'm able to generate the parts of my app incrementally (the facades, the business objects, the SQL scripts, the UI, etc) in kind of an on-demand way : you select model elements in the designer, and choose which contextual code generation step to perform on that element.
On an one-gigabyte RAM computer, the memory footprint of dynamically compiling a C# "script" to implement the code generator's command launcher is not big, since, by design, my IScriptedCommandHandler are supposed to be short (less than two hundred lines of code). Of course, that maybe an issue if you leave your VS environment open during several days, with hundreds of right-clicks. But I decided it would "normally" be very seldom the case.
My two cents,
Hi Stuart, Thanks for publishing the information about the plan. I would honestly like to see "First class support for cross-referencing between different models and multiple views" sooner rather than later.
If it is later, could you either maintain or "open the source" to the DIS powertoy (it contains great references about how to load and inspect the model so that you can cross reference models).
I would also like Microsoft to provide better template highlighting - without the need for clarius 74 template highlighter (it is a great editor however).
I would also like to have the ability have a template run across all models of a certain type so the following template directive:
requires="fileName='..\..\..\..\Data Access Model\Sample.repos'" #>
requires="fileName='..\..\..\..\Data Access Model\*.repos'" #>
This will stop me from having to hard code my model file into the template.
Thanks for your time.
Hi, futhermore to my previous comment.
I would love to see some extra shape types as standard, one such shape could be a UML style lifeline. I belive one could custom code this but it is a lot of effort and would be specfic to a developer and not the community as a whole. Is this type of extensibilty where you see WPF for the designer surface being used?