Create web service project within SharePoint context so web services can be automatically deployed to a SharePoint web application.

I want to deploy my InfoPath forms with the Factory.

Support for the deployment of Microsoft Dynamics CRM 4.0 customizations and custom components.

Templates are very usefull, but get in the way of the actual product.

I would like to see templates included in (or besides) the tools folder, so they don't "interfere" in the actual product.

This also prevents deploying templates along with the actual product.

MSF is used in scenarios where webservices are used. There is (to my knowledge) no guidance or support related to having multiple versions of service or message contracts.

This is something that needs to be done correctly from version 0.1 up, to prevent introducing problems later on, when introducing new contracts.

Make use of the stsadm -upgradesolution command when upgrading a SharePoint wsp.

This is a placeholder idea to collect CDI improvements.

1) Add database name override for CDI projects. E.g. to support customer database naming conventions, or environment-specific database names.

UPDATE: allow to specify custom database name suffix in machine config, so the first part of the name will still comply to MAST conventions and script logic based on database names will remain valid.

2) Remove MSBuild from the deploy logic, it has fundamental limitations that block defect fixes and enhancements.
Just use powershell directly against MSBuild tasts library of class library.

So instead of reimplementing functionality, reuse already implemented code

This tool generates mapping code between types in two assemblies. Integrate the tool in the Factory IDE and add a Factory Guide action that generates mapping code between Business.Entities and Business.ServiceInterfaces.Entities.

At the moment releasing a consoleUI or a winforms application means deploying a whole bunch of assemblies.

Using ILMerge to create a single application file with all the specific versioned assemblies makes managing the application easier.

Note that we need to change the name of the config file accordingly.

Organize a procedure to have code be reviewed upon requested by the project-manager and or the developer.

By default, users should be able to logon with their Macaw account on the virtual machines created by the Factory Machine Installer and then be a local admin.

This will allow seamless integration between the factory platform components (TFS, Wiki, Services) with a much better user experience.

This feature should be optional (opt-out); the machines should be excempted from the regular Macaw domain policies.

E.g. a safe way to do this could be to create a new domain and have a one-way trust to the Macaw domain.

Wanted:
- VM create machine screen: validate machine name to macaw standards.
- Better readability (display fields are too short)
- Application menu: enforce and indicate inclusions and exclusions
- Make the whole machine creation process, a single click operation

We will do this as part of a planned big SP 2010 Intranet project. It will also require supporting development on 64 bit OS es since SP 2010 will be 64 bits only.

In CDI projects the database create statement is generated for you on the fly when needed, but sometimes you want to specify additional elements in the database create statement. These elements may also be environment specific.

The Factory is already designed to support SOA solutions - each logical service is a MAST product, independantly versioned and deployed. ESB Guidance would add explicit SOA support for the shared SOA infrastructue itself.