This is a weird one. When unfolding t4 templates, NuPattern tries to close windows that might have been opened when adding a file (https://github.com/NuPattern/NuPattern/blob/be18383399bf1db558e52dd98e9af40a6fc45807/Src/Common/Source/Common.VisualStudio/Solution/VsFileTemplate.cs#L67-74)

                //
                // The file may have opened anyway, if we're not supposed to open it, we'll search for
                // the matching window and close it
                //
                foreach (EnvDTE.Window w in container.DTE.Windows)
                {
                    if (newlyAddedFile.Equals(w.ProjectItem))
                    {
                        w.Close(EnvDTE.vsSaveChanges.vsSaveChangesNo);
                        break;
                    }
                }

If one of the open windows is a Project Properties page, asking the window for its ProjectItem throws an InvalidCastException.

Repro steps with the MVC sample:

1. Create a new app
2. Build.
3. Open the properties of the MVC app project
4. While the property page is still open, add a controller.

You'll get an error:

NuPattern.Library.Automation.EventAutomation Error: 0 : Event automation 'GenerateControllerOnInstantiate' failed.
System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'EnvDTE.ProjectItem'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{0B48100A-473E-433C-AB8F-66B9739AB620}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
   at Microsoft.VisualStudio.Platform.WindowManagement.DTE.Window.get_ProjectItem()
   at Microsoft.VisualStudio.Platform.WindowManagement.DTE.WindowBase.<get_ProjectItem>b__2c()
   at Microsoft.VisualStudio.Shell.ThreadHelper.Invoke[TResult](Func`1 method)
   at Microsoft.VisualStudio.Platform.WindowManagement.DTE.WindowBase.get_ProjectItem()
   at NuPattern.VisualStudio.Solution.VsFileTemplate.Unfold(String name, IItemContainer parent)
   at NuPattern.VisualStudio.Solution.VsFileContentTemplate.Unfold(String name, IItemContainer parent)
   at NuPattern.VisualStudio.Solution.VsItemContainerExtensions.AddContent(IItemContainer parent, String content, String name, Boolean overwrite, Boolean openFile, Encoding encoding)
   at NuPattern.Runtime.UriProviders.TextTemplate.Unfold(String name, IItemContainer parent)
   at NuPattern.Library.Commands.GenerateModelingCodeCommand.Execute()
   at NuPattern.Library.Commands.GenerateProductCodeCommand.Execute()
   at NuPattern.Library.Automation.CommandAutomation.Execute(IDynamicBindingContext context, Boolean withAutomation)
   at NuPattern.Library.Automation.CommandAutomation.Execute()
   at NuPattern.Library.Automation.EventAutomation.ExecuteCommand()
   at NuPattern.Library.Automation.EventAutomation.<>c__DisplayClassd.<Execute>b__a()
   at NuPattern.VisualStudio.TraceSourceExtensions.DoShield(ITracer traceSource, Action action, String format, Boolean showUI, String[] args)

This is arguably an issue in VS's code, but NuPattern could catch this exception and avoid failing. From what I could see there is no way to query the window to see if it would throw when returning its ProjectItem, as the properties have values just like the window for a code editor:

        window.Caption  "Solution Explorer" string
        window.Type vsWindowTypeSolutionExplorer    EnvDTE.vsWindowType
        window.Kind "Tool"  string
        window.ProjectItem  null    EnvDTE.ProjectItem

        window.Caption  "Application1.Contracts"    string
        window.Type vsWindowTypeDocument    EnvDTE.vsWindowType
        window.Kind "Document"  string
+       window.ProjectItem  'window.ProjectItem' threw an exception of type 'System.InvalidCastException'   EnvDTE.ProjectItem {System.InvalidCastException}

        window.Caption  "EndpointConfig.cs" string
        window.Type vsWindowTypeDocument    EnvDTE.vsWindowType
        window.Kind "Document"  string
+       window.ProjectItem  COM Object  EnvDTE.ProjectItem {System.__ComObject}

A try/catch on InvalidCastException on that look should fix this.

When new target framework versions become available, VS updates the vstemplate schema to include them. This breaks the vstemplate file code in NuPattern generated with xsd.exe, which generates an enum for the restriction type

<xs:element name="RequiredFrameworkVersion" minOccurs="0">
<xs:annotation>
<xs:documentation>
<!--
 _locID_text="RequiredFrameworkVersion" _locComment="" 
-->
Specifies the minimum .Net Framework version required by the template.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="2.0"/>
<xs:enumeration value="3.0"/>
<xs:enumeration value="3.5"/>
<xs:enumeration value="4.0"/>
<xs:enumeration value="4.5"/>
<xs:enumeration value="4.5.1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

The matching code in NuPattern, generated with an earlier version of the schema file, looks like this:

    [System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "4.0.20918.0")]
    [System.SerializableAttribute()]
    [System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true, Namespace = "http://schemas.microsoft.com/developer/vstemplate/2005")]
    public enum VSTemplateTemplateDataRequiredFrameworkVersion
    {

        /// <remarks/>
        [System.Xml.Serialization.XmlEnumAttribute("2.0")]
        Item20,

        /// <remarks/>
        [System.Xml.Serialization.XmlEnumAttribute("3.0")]
        Item30,

        /// <remarks/>
        [System.Xml.Serialization.XmlEnumAttribute("3.5")]
        Item35,

        /// <remarks/>
        [System.Xml.Serialization.XmlEnumAttribute("4.0")]
        Item40,
    }

The suggested solution is to just deserialize the property as a string, rather than an enum. It's not currently being used by NuPattern, just deserialized as part of the schema.

Present

NuPattern is gasping for its last breath.

I am very sad to see it didn't live long enough to add value to many developers lives.
We failed to reach developers in the way intended. The tool fell into irrelevance. Community participation (above the core contributors) has really been non-existant. And there are few signs of usage and conversation about usage, anywhere (i.e. project site, or stakoverflow).

The value proposition was poorly understood by developers, not sufficiently communicated by us, and the benefits were hard to realize quick enough for many who tries. That's all on me.

Being constrained to a version of Visual Studio, and with its deep integration into Visual Studio has been very hard to keep up with a new release every two years, especially when the integration points with the IDE so radically change that often. As such, without community support, the project contributors have found it hard to commit time and resources to maintain the roadmap of NuPattern.

There have been a small number of people who have realised great benefits from this tooling platform (author included), but those successes are few and far between to keep an open-source project alive.

The market has spoken - we didn't get there.

Future

What I think we need is a better explained value proposition, and to appeal to a broader community of developers who could seriously benefit from this capability every day that does not hitch its value to any particular tech trend or IDE (as NuPattern did to MDD and Visual Studio).

I think we need to move to a hosted SAAS type model, with a consistent API and UI that integrates with existing tools like github and others etc. To be more successful for many more developers. Its got to be easier to realise more value, quicker.

We have to position it right, we have to be clear about why, and who our customers really are.
We have to deliver it in a way that is free from host environment impediments, and where its value is easily delivered over the web as part of existing tool chains.

The value proposition has not really changed, and the demand for better refactoring and automation tools has only increased in the last decade. We fit squarely into that space, and could even propel it forward.
Developers who create solutions/products still spend a great deal of time designing, refactoring and repeating patterns in their code.
So much time is spent creating patterns so often in so many places across a code base that refactoring the pattern across a whole code base eventually becomes too menial to do effectively.
Instead a new version of the pattern is copy-pasted, evolves in isolation, and co-exists with the legacy ones.
These problems still exist for most developers building solutions/products that wont change in the foreseeable future.
If we can position ourselves to tackle that space, and to become part of solving that problem, more developers may start to see the value proposition we offer sooner.

There is a general dislike by many master software folk for code generation, because of the legacy experiences with code generators that tried to specify the patterns. They feel like code generation automation in general robs engineers of creativity and reasoning, and creates non-optimal bloatware.
That is not the space we are in. We need to avoid that space, and instead address the space of helping you templatize your own patterns, and reapplying them once you have iterated and optimized them.

Now that NuPattern has proven the value of this kind of tooling, and demonstrated it is feasible. I would like to take that learning and evolve a different tool that embodies the value of this tool, but that is more applicable to more people, and can fit more friction-free within their tool-chain of development.

I propose the auto-mate project to chart that evolution.

I'd like to hear your thoughts and support on that?