If I want to Large Scale Generation and define
Application = Framework (binary core components) + Generated Code + Custom Code
How would I go about creating code generation framework using scaffolding to generate multiple projects and associated files from some metadata (let's say a DSL model defined in a solution folder)
I know that I can use MvcScaffolding powershell cmdlets to add files to the current on another project.
I need to know if I can add a new project (Class library, Web appication) to the current solution from some kind of project template, apply source transformation and possibly merge some custom data. That would allow additional files to be added and I would prefer that both creation of the project and adding some files initially be done in one powershell line based on some input parameters (let say the name of some DSL model, XSD schema, XML data)
Could I just create a new solution and invoke some scaffolders? Are there scaffolders at a solution level?
I would like to have a scaffodling framework resembling software factories (Web service software factory). Any samples, ideas, articles?
Thanks
Rad
I don't see any reason why not.
Your T4 templates can access EnvDTE and so do all sorts of fun VS automation, and of course the .ps1 powershell scripts can (I guess - I am no powershell guru) do pretty much anything you yourself can do on your box.
But out of interest why would you want to generate whole projects? i.e. are you sure that is time saving?
Related
I have 5 basic projects that need to be part of multiple applications. WinForms, ASP.NET, WPF depending on the needs we have.
These Projects are:
Company.Business - Business Logic DLL
Company.Business.Model - Business Models
Company.Business.DAL - Various DALs
Company.Configuration.Classes - Classes that are used to initialize BOs
Company.Utilities - General Utilities
Now i am trying to decide how i should go about when i create new UI solutions?
1) Include the projects by Add->Existing project ?
2) Copy the compiled .dlls to each solution manually?
In case of option 2 where i should do the basic development for all the above? Probably a separate solution that includes them all? and in there i should start unit testing?
My take on this is that it depends on your needs and how mature the "basic" projects are.
Your needs
If you need to look at into the code of the "basic" projects while working on the using-projects, then I'd add them to the current solution with the add-existing project method. In situations with multiple added existing projects I make a solution folder called "referenced projects" and add them in this folder.
Maturity
If your "basic" projects are still being developed (perhaps side-by-side) with the using-projects I'd also would add them in the solution as described above.
But if you have no need to look at the code then you might as well include the compiled dll in your client-projects.
Harry
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I am curious what the preferred way to structure an application with an executable client program, an executable server program and a shared model in solutions and projects (using Visual Studio and C#). Being used to Java development I initially regarded projects as packages and defined a project for each package I designed.
This resulted in a six-project solution (one for the model, one for the server and four for the client) which in turn resulted in some silly dependencies causing me to reconsider if this is the best approach.
Now, I am planning to restructure the solution to three projects total: a client project, a sever project and a model project. Both the client and the server will be dependent on the model project (in which I will also add the shared interface between client and sever).
Is this the best way to structure such an application?
Also, what is the best way to reflect namespaces within the tree structure of Visual Studio? (Just creating a similar folder structure for instance?).
A 3-project solution (client / server / model) is indeed the norm for your scenario.
Regarding namespaces: Yes, your folder structure should reflect the namespaces you are using. The default namespace can be set in the project properties, folder names are added to that namespace.
My team is creating some standard VS solution templates. We have a well-defined project structure, resources, etc. that we need to use every time we start a new project and this is the perfect solution. The basics work nicely.
However, as well as defining folder structure (etc.) it would be nice to be able to import a number of projects from VSS/TFS. We have a number of shared assemblies that will be used by all projects and it would be awesome to add a reference to these projects when creating a new project via our template. Can anyone tell me if this is possible and, if so, how it can be achieved?
I think there are 3 types of items you might want to templatize (is that a word?).
New Solution
New Project added to a solution
New item added to a project
I'm not sure whether its possible to add existing projects to the solution that is created when a project template is run. http://msdn.microsoft.com/en-us/library/ms185308.aspx shows how to create multiple project templates. You may have to either manually add them to the solution or create a script that modifies the .sln file to do that part.
Adding an assembly reference to either a project or item template is easily doable. The project template is pretty simple since you just need to modify your .vstemplate file for the project template(s). See http://msdn.microsoft.com/en-us/library/ms171405.aspx for reference.
Adding a new assembly reference when you add a new item from a template is a bit harder but can also be done. See http://msdn.microsoft.com/en-us/library/ms185290.aspx for more.
Have fun!
How do I create a Web Application Project in VS 2008? How is it different from a "WebSite" project?
File--New--Project
instead of File--New--Web Site
It acts as a different container all together and the compile model is different.
ScottGu provided some details when they were first launched: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
The main difference is that Web application uses .csproj file which holds the information about all the files in the project. What difference does it make? Using web site model you can add new files without visual studio, since adding new files doesn't require csproj file modifications, but using Web application model you can not.
I personally prefer Web application type.
People have adequately identified many differences, but let me add this broader stroke:
Web Application Projects are architecturally consistant with the other project types in .Net, whereas WebSites deviate and really seem like a throwback to the VS 2003 days.
For this reason, my opinion is that WAP's are more elegant (especially when you have more than one project in a solution).