I am trying to use T4 for source code generation. Mostly, I am able to generate individual files using it. How do I create a complete Visual Studio directory (preferably separate from the T4 template directory) having the below sample structure:
/MyProject – Contains MyProject.sln.
/app - Contains the core project layers.
/MyProject.ApplicationServices
/MyProject.Core
/MyProject.Data
/MyProject.Web
/MyProject.Web.Controllers
/build - Empty folder for housing build related stuff.
/lib - Contains the solution items for the deployable application.
/db - Contains database schema information; e.g., the result of scaffolding and/or NHibernate's schema export.
/docs - Project documents.
/logs - Output location for log files.
/tests
/MyProject.Tests
/tools
/lib - Contains the solution items for the tests project and all other non-deployable assemblies.
/CrudScaffolding - Customizable CRUD, scaffolding generation code.
You may take a look at the Guidance Automation Extensions and Toolkit for Visual Studio from Microsoft. They are intended for exactly that purpose to be able to author project and solution generation wizards and leverage T4 a lot. In fact, they are the reason why T4 came into being in the first place. However, as they can be seen as a "Software Factory Factory", they do have a steep learning curve.
As herzmeister der welten mentions, I do think Guidance Automation could do this sort of job, but it is quite a learning curve.
Here are a couple of other options:
Damien Guard has a post on how to generate Multiple outputs from T4. However, it's probably not well-suited for creating lots of different types of files. If you have many files to create of a similar type (e.g. several code files, various project files, etc) that you want to create, his technique would be quite useful.
Another option would be to combine your existing T4 templates and knowledge and create your outputs using command line T4. For example, you could simply use a .bat file that executes various commands to generate the necessary outputs using T4 and your existing templates. The downside here is that it is difficult to pass arguments into the command line utility, but there are some workarounds to that problem too.
Related
Context:
I have a few projects in the same solution which I push through a pipeline that packs them into NuGet packages and stores them in my Azure Artifacts storage.
The steps are:
Install NuGet
NuGet restore
Build solution
Run tests
NuGet pack (dotnet pack, to be specific, as they are .NET Standard targeting)
NuGet push (to Artifacts storage)
However, the solution contains a few yet unfinished package projects that I don't want to pack yet as well as my test project, which should also be excluded.
Simple enough, in that case my file matching pattern would just include the names of the projects I want, like:
'**/*Proj1.csproj;**/*Proj2.csproj;**/*Proj3.csproj;'
But now I want a few new projects to be added to this shipping 'set'. Therefore my pattern will have to include them as well.
'**/*Proj1.csproj;**/*Proj2.csproj;**/*Proj3.csproj;**/*Proj4.csproj;**/*Proj5.csproj;'
As you can see, that's hardly generic. I have to modify the pattern every time something changes, gets included, or if I reverse it - every time I want to exclude a project.
I'm looking to apply the same pipeline, or at least the structure (as much as I can), to a few solutions of the same type, which I'd like to make possible with a few naming conventions I have in place.
Question:
Is there a way to turn:
'**/*Proj1.csproj;**/*Proj2.csproj;**/*Proj3.csproj;**/*Proj4.csproj;**/*Proj5.csproj;'
into
'**/Packages/**.csproj;' //or something very similar
Where 'Packages' is a VS Solution folder (because actual folders don't work inside the base of a solution), with the end goal being every project inside the 'Packages' solution folder being discovered (and packed), and ignoring everything outside of it.
The problem being that solution folders are not an actual part of the path structure...
PS -
Workarounds I have considered -
Have a keyword in the names of all projects I want to ignore like "Foo.Ignore.csproj" and then exclude all that contain "Ignore" in the name.
Unloading/removing the unfinished projects from the solution but a) I want to make sure they are held in buildable and testable state and b) since they remain in the repository path, they are still discoverable by the matching pattern.
However I don't feel like this is such a far fetched use-case that it wouldn't have a "supported" solution (I could be wrong, of course). Or there is a different 'best practice' established?
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.
I created an ecore-Metamodel, a genmodel and a corresponding model.
Now I want to generate Code from this.
I found this post and wanted to implement it. I get no errors and so on, but how do I bring the CodeGenerator to generate the wanted output in a File like 'test.txt' (taken that example from the referenced question)?
Do I require a workflow file (mwe2) or do I miss something?
I only needed to run the application as Java and the code worked. I don't need any workflow or mwe2!
But appearently I still cant create the files like I can with a Generator.
I just can use a simple filewriter.
In the symfony framework, a great many files are auto-generated at various stages of development. Some of these files are meant to be edited and manually-customized while others are meant to never (or very rarely) be hand-edited but instead to change as the result of changes to other configuration or settings files.
Which symfony files fit into this latter category of "avoid hand-editing"? I want to know so I can exclude these files from revision-control. Another reason to know is simply to know which files I should avoid editing.
Note that the GitHub project gitignore has both .gitignore files for symfony or symfony2 projects:
symfony.gitignore:
cache/*
log/*
web/uploads/*
config/databases.yml
config/propel.ini
data/sql
lib/filter/doctrine/base/Base*
lib/form/doctrine/base/Base*
lib/model/doctrine/base/Base*
lib/model/om/*
lib/model/map/*
symfony2.gitignore:
*/logs/*
*/cache/*
web/uploads/*
web/bundles/*
That illustrates the differences and evolutions of the structure of a symfony project.
Don't edit anything that starts with Auto or Base as these files are recreated when you run various build tasks. Edit the files that extend from these classes instead.
Can anyone share his experience on workflow for R peject development under ESS? I tried several times to learn emacs but I have not get it yet. I can understand ESS as an editor, but is there a project view in ESS? what's the efficient ways to set up/view R project directory, coding, and testing, and how's ESS has an edge to facilitate the whole process?
Do you use ESS as a good R editor only or tend to emulate a R IDE environment within ESS?
Thanks for any advices.
It sounds like you're asking two separate questions.
One question concerns workflow and the other concerns using ESS.
As I use StatET and Eclipse, I'll just share my experience regarding the workflow aspect of your question.
As with Vincent I also follow something like the workflow set out by Josh Reich here (also see Hadley's useful comments):
Workflow for statistical analysis and report writing
Although it can vary between projects, I tend to have a couple of main R files
import.R: this imports data files and does any necessary cleaning and manipulation
analyse.R: This generates the output that I need for any final report
main.R: This calls import.R and analyse.R
The aim is for import.R and analyse.R to represent the complete and final workflow for producing the final results of any analyses.
In terms of a directory structure for an analysis project, I'll often also have the following folders
data: for storing any raw data files
meta: for storing meta data, such as variable labels, scoring systems for tests, recoding information, etc.
output: for storing any graphics, tables, or text generated by my analyses that I might want to incorporate into an external program
temp: When exploring the data and brainstorming analyses, I like to type code into files instead of using the console. I tend to label these temp1.R, temp2.R, temp3.R. I store these in a temp folder. That way I have a permanent record that's easily accessible. If the analyses become final they get incorporated into one of the main R files (i.e., import.R or analysis.R)
functions: If I think that a function will be needed across a couple of projects, I often place it one function per file or a set of related functions in a file in a folder called functions. This makes it relatively easy to reuse functions across projects, when the formal requirements of package development are more than needed.
library: If I want to create some general functions that I think will be project specific, I'll place them in this folder
save: A folder to store any saved R objects
StatET and Eclipse make it easy to interact with such a file system.
Of course, given all the R gurus that use ESS and Emacs, I'm sure it also handles interactions with the file system well.
I'm not exactly sure what you expect as an answer on this one. I, for one, have stolen (and adapted) a system that was suggested here a little while ago (by Josh Reich):
Create a folder for every project, and split up your work in a bunch of different .R files:
Load.R for getting your raw data into R;
Prep.R for cleaning the data, recoding variables, etc.;
Func.R for coding any custom functions you will need for evaluation; and
Eval.R for running your final stuff.
If that doesn't fit your style, just change it.
Then, you can either have a master file to call each of the parts one after each other (good for reproducibility), or save at different stages and have the individual scripts load the appropriate data (good if some of the prep work is very computationally/time intensive).
**
On a different note, the trick that is posted at the link really helped me get into ESS. It turns Shift-Enter into a one-stop-ESS-shop: http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/
Others have given you some good ideas about how to setup your directory/file structure for a project.
You also asked about "project views," in which case you might want to look into the Emacs Code Browser (ECB).
You can find some screen shots of it in action on its site, here:
http://ecb.sourceforge.net/screenshots/index.html