NuPattern

Source code checked in, #36c1b94d44145b75fb7a477d483bbd364913861a

jezzsa — Wed, 22 May 2013 03:18:08 GMT

Added missing dependencies of Microsoft.VisualStudio.Modeling.Sdk.DslDefinition.1X.0 for enabling text transformation on the build server Updated CI.proj to build debug targets

Edited Issue: Decouple VSIX ID from Toolkit Asset References [127]

jezzsa — Tue, 21 May 2013 23:58:57 GMT

# Issue
Currently, (v1.3.21.0) several toolkit assets that are configured in automation in the Pattern Model (i.e Text Templates, Guidance Workflow, etc), use a reference that includes the VSIX ID of the Toolkit VSIX package.
The reason for this, is so that at runtime a toolkit can load its assets from the correct toolkit.
Note that tailored toolkits need to be able to load assets from their base toolkits. So potentially, a toolkit could be loading assets from any installed toolkit on the machine.
To be able to find the original toolkit owner of the asset, the VSIXID was included in the reference, and then used to lookup the toolkit VSIX from the Extension Manager in VS.

This was the original reason NuPattern uses the VSIX ID in these asset and automation references.

At this point in time, there are emerging scenarios especially around toolkits that need to be built for different versions of VS, where the VSIX ID needs to unique between different versions of toolkits.

What is required now, is to divorce or uncouple the VSIX ID from the ID of the toolkit itself. Allow the VSIXID to be independent of the ToolkitID, but have a way to correlate them to achieve the same mechanisms as described above.

# Suggestion
* Every toolkit should have a unique VSIXID, and a unique 'ToolkitID'.
** Existing/Legacy toolkits could be updated to define both, but at least will share the same values until updated. And then updated using the SchemaUpgrade mechanism next time they are compiled.
** New toolkits will generate different IDs.
* The toolkit author can control the VSIXID - as they always could, but the ToolkitID is generated for them. **No real reason for an author to change the ToolkitID.
* The ToolkitID is used to reference all toolkit assets and automation - Not the VSIX ID.
* The IToolkitInfo interface should be modified to support a ToolkitID as well as the VSIXID, and then used to correlate them by the automation.

Created Issue: Decouple VSIX ID from Toolkit Asset References [127]

jezzsa — Tue, 21 May 2013 23:58:32 GMT

# Issue
Currently, (v1.3.21.0) several toolkit assets that are configured in automation in the Pattern Model (i.e Text Templates, Guidance Workflow, etc), use a reference that includes the VSIX ID of the Toolkit VSIX package.
The reason for this, is so that at runtime a toolkit can load its assets from the correct toolkit.
Note that tailored toolkits need to be able to load assets from their base toolkits. So potentially, a toolkit could be loading assets from any installed toolkit on the machine.
To be able to find the original toolkit owner of the asset, the VSIXID was included in the reference, and then used to lookup the toolkit VSIX from the Extension Manager in VS.

This was the original reason NuPattern uses the VSIX ID in these asset and automation references.

At this point in time, there are emerging scenarios especially around toolkits that need to be built for different versions of VS, where the VSIX ID needs to unique between different versions of toolkits.

What is required now, is to divorce or uncouple the VSIX ID from the ID of the toolkit itself. Allow the VSIXID to be independent of the ToolkitID, but have a way to correlate them to achieve the same mechanisms as described above.

# Suggestion
*Every toolkit should have a unique VSIXID, and a unique 'ToolkitID'.
** Existing/Legacy toolkits could be updated to define both, but at least will share the same values until updated. And then updated using the SchemaUpgrade mechanism next time they are compiled.
** New toolkits will generate different IDs.
*The toolkit author can control the VSIXID - as they always could, but the ToolkitID is generated for them. **No real reason for an author to change the ToolkitID.
* The ToolkitID is used to reference all toolkit assets and automation - Not the VSIX ID.
* The IToolkitInfo interface should be modified to support a ToolkitID as well as the VSIXID, and then used to correlate them by the automation.

Closed Issue: Provide full high-res icons of NuPattern [124]

jezzsa — Tue, 21 May 2013 23:44:07 GMT

Currently I could only find a small icon png with the NuPattern logo. We need the high-res ones on the source tree too.

Closed Issue: Custom automation doesn't work with default toolkit template [126]

jezzsa — Tue, 21 May 2013 23:43:19 GMT

At least with type converters, VS can't find the types because the default template does not tell VS that the toolkit should also provide a binding path.

This is typically added when you have a VS Package, via the [ProvideBindingPath] attribute.

One way to solve this is to simply provide a .pkgdef file together with the toolkit, containing something like this:

[$RootKey$\BindingPaths\{SOME_RANDOM_GUID}]
"$PackageFolder$"=""

And configuring this file as Content / IncludeInVsix = true, alongside the corresponding <VsPackage> node in the manifest.

The attached toolkit reproduces the problem. If you remove the <VsPackage> node in the source.extension.tt file, the enum values for the Locale property on the VisualStudioExtension pattern element is not shown (actually, an error shows saying no standard values are supported). Bringing back that XML node fixes the issue since now VS can find the type for the type converter.

Comments: Fixed in https://nupattern.codeplex.com/SourceControl/changeset/e796c4b0707428728a9680aa47376dd52bf161ab

Closed Issue: TypeResolution in VS2012 Problems [100]

jezzsa — Tue, 21 May 2013 23:42:59 GMT

# Issue
In the development of 1.3.20.0, in the process of creating a version of NuPattern for VS2012, we discovered that partially named types were not being loaded in VS2012. But thery were working fine in VS2010.

Partial type names such as those used to define things like TypeConverters, TypeEditors .etc in the pattern model.

We found that we needed to add a custom assemblyresolver for NuPattern in VS2012 (only) that could resolve partial names of types in a toolkit to a loaded tookit which should already be in the current AppDomain.

This fix seemed to resolve many of the partial type loading.

However, it is now apparent that we still have issues with partially defined types declared in the pattern model. For example, in the mvcpat there are a few custom TypeConverters created and declared on properties in the pattern model.

At runtime, none of these TypeConverters are used. In debugging, it is clear that the PropertyPropertyDescriptor which should use the custom TypeConverter, and is indeed assigning it correctly in the ctor, but the base class PropertyDescriptor is ignoring the type and defaulting to a StringConverter. Perhaps the base class is having problems loading the specified type and ignoring it?
Either way, we are not having the same issues in the VS2010 version, where partially declared types are working just fine.

# Suggestion

We need to investigate what exactly is failing in the PropertyDescriptor class, and find a way to workaround it for VS2012.

Comments: Fixed in https://nupattern.codeplex.com/SourceControl/changeset/e796c4b0707428728a9680aa47376dd52bf161ab

Edited Issue: TypeResolution in VS2012 Problems [100]

jezzsa — Tue, 21 May 2013 23:42:29 GMT

Edited Issue: Custom automation doesn't work with default toolkit template [126]

jezzsa — Tue, 21 May 2013 23:42:14 GMT

Source code checked in, #e796c4b0707428728a9680aa47376dd52bf161ab

jezzsa — Tue, 21 May 2013 23:37:45 GMT

Removed other redundant assembly resolution code

Commented Feature: Setup continuous integration [96]

jezzsa — Tue, 21 May 2013 22:14:17 GMT

# Issue
Having a CI build has many benefits. if nothing else but a clean build and test environment to keep everyone honest.

TeamCity is well-known platform for CI.
The NuPattern project has a full -license for TeamCity.

# Suggestion
Anyone with TeamCity experience?
Please help us decide what the options are, what tools we need, and how set this up for the project.
And of course whether we should or not?
Comments: All VS assemblies we reference are there (or should be). I dont beleive we are in breach of any license, as we dont redistribute them - unless I misunderstand that somehow.

Updated Wiki: Follow

jezzsa — Tue, 21 May 2013 22:02:38 GMT

Following NuPattern

Here are some of the ways you can follow what's happening on the NuPattern project:

Subscribe to one of the various feeds from this site.
- Click the Subscribe link to the right of this page for a menu of the different feeds you can subscribe to.

Follow the project on twitter: @nupattern

Follow the NuPattern blog, and of some of the regular project contributors:
- NuPattern Blog - Build Your Own Tools
- Jezz Santos - From Software Factories to Software Automation

We have a youtube channel: NuPattern Channel

We also have a Google Hangout for anyone who wishes to discuss live. We may look at scheduling regular meetings if people want to specify a good time.

Commented Issue: Provide full high-res icons of NuPattern [124]

jezzsa — Tue, 21 May 2013 20:46:57 GMT

Currently I could only find a small icon png with the NuPattern logo. We need the high-res ones on the source tree too.
Comments: wiki link fixed

Updated Wiki: Where is the Documentation?

jezzsa — Tue, 21 May 2013 20:46:36 GMT

Where is the Documentation?

The NuPattern toolset installs extensive and integrated documentation and guidance for explaining Pattern Toolkits, including a User's Guide, and Builder's Guide that covers topics like: why they exist? how to run them? how to built them? and how can they be extended and customized?
This guidance is both informational and instructional and is contained within the extensions installed with NuPattern.

The product documentation for NuPattern is installed by installing the 'NuPattern Toolkit Builder' extension, and can be seen in Visual Studio, and also Online
The documents for the NuPattern project itself are also Online

View the Documentation in Visual Studio

Just install the current release of the 'Pattern Toolkit Builder' extension, start Visual Studio, and in the top of the 'Solution Builder' window (CTRL + W, H), hit the 'Guidance' button

The extensions above install a copy of the guidance (as an volume of *.MHT files, one file for each topic). This is how the 'Guidance Workflow Explorer' tool window consumes each topic when viewed in Visual Studio.
If you are interested in the individual topics, you can find these MHT documents in the installation folders of the extensions themselves. For Visual Studio 2010, those can be found under: %localappdata%\Microsoft\VisualStudio\vsver\Extensions\Microsoft\extension

View the Documentation Online

If you want to browse the documentation outside of Visual Studio, we have including the compiled and indexed PDF versions of the guidance in PDF documents that can be browsed and printed.

Please download those PDFs from the latest released version.

Note: At some point in the future, this documentation will be hosted online.

Project Documentation

The documents for the NuPattern project itself are shared on a Skydrive
These project documents contain images, documents and other resources used for planning and documentation, and also contain copies of documents used on the project sites.

Please let the Project Owner know if you need write access to any of these folders or files.

Commented Issue: Custom automation doesn't work with default toolkit template [126]

dcazzulino — Tue, 21 May 2013 20:06:50 GMT

At least with type converters, VS can't find the types because the default template does not tell VS that the toolkit should also provide a binding path.

This is typically added when you have a VS Package, via the [ProvideBindingPath] attribute.

One way to solve this is to simply provide a .pkgdef file together with the toolkit, containing something like this:

[$RootKey$\BindingPaths\{SOME_RANDOM_GUID}]
"$PackageFolder$"=""

And configuring this file as Content / IncludeInVsix = true, alongside the corresponding <VsPackage> node in the manifest.

The attached toolkit reproduces the problem. If you remove the <VsPackage> node in the source.extension.tt file, the enum values for the Locale property on the VisualStudioExtension pattern element is not shown (actually, an error shows saying no standard values are supported). Bringing back that XML node fixes the issue since now VS can find the type for the type converter.

Comments: Fixed on pull request https://nupattern.codeplex.com/SourceControl/network/forks/dcazzulino/contrib/contribution/4774

Commented Issue: TypeResolution in VS2012 Problems [100]

dcazzulino — Tue, 21 May 2013 20:06:43 GMT

# Issue
In the development of 1.3.20.0, in the process of creating a version of NuPattern for VS2012, we discovered that partially named types were not being loaded in VS2012. But thery were working fine in VS2010.

Partial type names such as those used to define things like TypeConverters, TypeEditors .etc in the pattern model.

We found that we needed to add a custom assemblyresolver for NuPattern in VS2012 (only) that could resolve partial names of types in a toolkit to a loaded tookit which should already be in the current AppDomain.

This fix seemed to resolve many of the partial type loading.

However, it is now apparent that we still have issues with partially defined types declared in the pattern model. For example, in the mvcpat there are a few custom TypeConverters created and declared on properties in the pattern model.

At runtime, none of these TypeConverters are used. In debugging, it is clear that the PropertyPropertyDescriptor which should use the custom TypeConverter, and is indeed assigning it correctly in the ctor, but the base class PropertyDescriptor is ignoring the type and defaulting to a StringConverter. Perhaps the base class is having problems loading the specified type and ignoring it?
Either way, we are not having the same issues in the VS2010 version, where partially declared types are working just fine.

# Suggestion

We need to investigate what exactly is failing in the PropertyDescriptor class, and find a way to workaround it for VS2012.

Comments: Fixed on pull request https://nupattern.codeplex.com/SourceControl/network/forks/dcazzulino/contrib/contribution/4774

Commented Issue: TypeResolution in VS2012 Problems [100]

dcazzulino — Tue, 21 May 2013 19:44:55 GMT

# Issue
In the development of 1.3.20.0, in the process of creating a version of NuPattern for VS2012, we discovered that partially named types were not being loaded in VS2012. But thery were working fine in VS2010.

Partial type names such as those used to define things like TypeConverters, TypeEditors .etc in the pattern model.

We found that we needed to add a custom assemblyresolver for NuPattern in VS2012 (only) that could resolve partial names of types in a toolkit to a loaded tookit which should already be in the current AppDomain.

This fix seemed to resolve many of the partial type loading.

However, it is now apparent that we still have issues with partially defined types declared in the pattern model. For example, in the mvcpat there are a few custom TypeConverters created and declared on properties in the pattern model.

At runtime, none of these TypeConverters are used. In debugging, it is clear that the PropertyPropertyDescriptor which should use the custom TypeConverter, and is indeed assigning it correctly in the ctor, but the base class PropertyDescriptor is ignoring the type and defaulting to a StringConverter. Perhaps the base class is having problems loading the specified type and ignoring it?
Either way, we are not having the same issues in the VS2010 version, where partially declared types are working just fine.

# Suggestion

We need to investigate what exactly is failing in the PropertyDescriptor class, and find a way to workaround it for VS2012.

Comments: Ok, the proposed fix for https://nupattern.codeplex.com/workitem/126 works (including a BindingPath.pkgdef with the vsix). This would be a breaking change for existing toolkit authors, but automatic for new ones using a new drop including this fix. Should we provide migration steps?

Commented Issue: Provide full high-res icons of NuPattern [124]

dcazzulino — Tue, 21 May 2013 00:07:44 GMT

Currently I could only find a small icon png with the NuPattern logo. We need the high-res ones on the source tree too.
Comments: Clicking on the wiki link takes me here: https://nupattern.codeplex.com/wikipage?title=https%3a%2f%2fskydrive.live.com%2fredir%3fresid%3d1C8F13692E8E8DC0%21108&referringTitle=Where%20is%20the%20Documentation%3f

Commented Feature: Setup continuous integration [96]

dcazzulino — Mon, 20 May 2013 23:53:48 GMT

# Issue
Having a CI build has many benefits. if nothing else but a clean build and test environment to keep everyone honest.

TeamCity is well-known platform for CI.
The NuPattern project has a full -license for TeamCity.

# Suggestion
Anyone with TeamCity experience?
Please help us decide what the options are, what tools we need, and how set this up for the project.
And of course whether we should or not?
Comments: There are a ton of VS references (I.e. DTE, shell, shell.interop etc.), which I don't see copied, neither I think you can per license... You can with SDK ones, which is what I think you're referring to

Commented Issue: Custom automation doesn't work with default toolkit template [126]

dcazzulino — Mon, 20 May 2013 23:52:58 GMT

At least with type converters, VS can't find the types because the default template does not tell VS that the toolkit should also provide a binding path.

This is typically added when you have a VS Package, via the [ProvideBindingPath] attribute.

One way to solve this is to simply provide a .pkgdef file together with the toolkit, containing something like this:

[$RootKey$\BindingPaths\{SOME_RANDOM_GUID}]
"$PackageFolder$"=""

And configuring this file as Content / IncludeInVsix = true, alongside the corresponding <VsPackage> node in the manifest.

The attached toolkit reproduces the problem. If you remove the <VsPackage> node in the source.extension.tt file, the enum values for the Locale property on the VisualStudioExtension pattern element is not shown (actually, an error shows saying no standard values are supported). Bringing back that XML node fixes the issue since now VS can find the type for the type converter.

Comments: Yes, fix would solve the second part of that issue, I believe

Commented Issue: Custom automation doesn't work with default toolkit template [126]

jezzsa — Mon, 20 May 2013 22:56:35 GMT

At least with type converters, VS can't find the types because the default template does not tell VS that the toolkit should also provide a binding path.

This is typically added when you have a VS Package, via the [ProvideBindingPath] attribute.

One way to solve this is to simply provide a .pkgdef file together with the toolkit, containing something like this:

[$RootKey$\BindingPaths\{SOME_RANDOM_GUID}]
"$PackageFolder$"=""

And configuring this file as Content / IncludeInVsix = true, alongside the corresponding <VsPackage> node in the manifest.

The attached toolkit reproduces the problem. If you remove the <VsPackage> node in the source.extension.tt file, the enum values for the Locale property on the VisualStudioExtension pattern element is not shown (actually, an error shows saying no standard values are supported). Bringing back that XML node fixes the issue since now VS can find the type for the type converter.

Comments: Is this related to https://nupattern.codeplex.com/workitem/100 ??