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.
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 may not fully understand the wiki article on scoping, so forgive me if this sounds dumb.
Intro:
I have a solution (ABC.sln) with over 40 projects and am trying to implement OpenWrap for package management.
So I did the following in the solution's root folder:
o init-wrap -all
That worked fine: I now have a file called SLN.wrapdesc in the solution's root folder. All of the .csproj files in the subfolders contain the OpenWrap targets line.
I then proceded to add the different wraps to the solution with:
o add-wrap -Name xxx
Again, this worked fine: I have some wraps in the wraps folder, and the build doesn't break after removing the old references from the projects.
Problem:
All of the contents of the wraps are going to all of the projects, even for those that don't need it. I would like to be able to specify which wraps go where, eg AjaxControlToolkit only goes into web projects.
What I tried
First, I removed the AjaxControlToolkit from the wrapdesc:
o remove-wrap AjaxControlToolkit
This causes the build to break (as expected). Then I tried the following:
1. Try to add the wrap back with a scope:
o add-wrap -Name AjaxControlToolkit -scope webproject
This simply puts the wrap back in the wraps folder. I then added <OpenWrap-Scope>customscope</OpenWrap-Scope> to the project file, but the build still broke.
2. Try and manually add a file called ABC.webproject.wrapdesc to the root folder. This causes the following error when I try to open the solution:
The "exists" function only accepts a scalar value, but its argument "#(_WrapFile->'%(FullPath)')" evaluates to "D:\Projects\ABC.webproject.wrapdesc;D:\Projects\ABC.wrapdesc" which is not a scalar value.
I guess it doesn't like 2 wrapdesc files. That is strange because the wiki says "...you can add a second descriptor alongside your default descriptor..."
So now I'm stuck. Anyone have any ideas?
The per-msbuild file is really not a recommended approach to managing dependencies. Doing it per project is not quite the design philosophy behind OpenWrap, so the system is not quite optimized for those scenarios.
If you don't need something from those assemblies then the easiest way to solve it is to not use the references by not using any code from those packages. This solves the problem very easily as nothing will get loaded (or even need to be on disk) if no code has been added to it.
That said, add-wrap -scope newscope will create an additional .wrapdesc file that will add the new dependency to the new scope, by creating a myProject.newscope.wrapdesc file independently of the original myProject.wrapdesc.
If you do want to do this per-project, have you tried using the convention-based scoping? Something like:
directory-structure: src\*{scope: Web=WebProjects}*
Would take any project in a folder child of src containing Web in the name and assign those to the WebProjects scope.
I know that one has worked fine for my projects so far, although you do have to restart VS as it aggressively caches certain files and will not see the change.
Customizing the msbuild file itself is not fully tested (and the wiki entry was very much a design spec rather than final documentation, not all of it has been built that way) so it may or may not work. Happy to take a look if you can open a bug ticket on http://github.com/openrasta/openwrap/issues
I have a legacy java project that we have been moving to buildr/artifactory from ant/jars in svn.
The primary code is in the default (src/main/java) folder, but we have a few external source paths, for various tests that we can't move into the default folder, but we want to have access with it.
Currently, when adding a new library/regenerating IDE fields, it does not pick up these source paths, and I can't find a succinct discussion in the buildr manual for how to actually add them, rather than re-adding everything manually in eclipse (which just gets wiped out on the next regen).
Any idea how to have multiple source paths get picked up explicitly by buildr so that the idea/eclipse targets generate properly?
There are two ways that I know will work with IDEA. The second one might also work with Eclipse, while the first is specific to the idea task.
The IDEA-specific solution:
define 'proj' do
# ...
iml.main_source_directories << _('src/other')
end
iml also has test_source_directories and excluded_directories arrays you can append to.
The possibly eclipse-compatible solution, with more background than you probably want:
The iml object gets its default values for the main and test source directory arrays from project.compile.sources and project.test.compile.sources (slight simplification; resources are considered also). Buildr defines these .sources project attributes from the layout, so instead of explicitly appending to the iml attributes, you could use a custom layout for your project that includes your special source paths. That might work with the eclipse task, but I haven't tried it.
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.
I'm trying to come up with a way to make it easy to switch out our "mock" data services and our live ones. Basically, we'll have live servers with real web services, but for whatever reason, a developer may want to load data from static files (file urls).
I figured I would solve this problem by creating categories that override the methods that fetch the data, thus leaving original code untouched (it has no concept of the "mock" data). I don't want to litter my code with #ifdef.
I can put an #ifdef at the very beginning of each file that has categories in it, and I can set a custom flag in the configuration settings, but I'd rather just have a way to include or exclude the files depending on the configuration. Is that possible? How do you solve this problem?
See http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
The trick is to define EXCLUDED_SOURCE_FILE_NAMES in the configuration you want to exclude the files from, and set the value of that custom build setting to a list of the file names (or a pattern that matches those, and only those, file names).
I would recommend creating two targets one of which has the mock categories included and another one which does not.
When you want to test, just build the target containing the mock categories. Everything else can remain identical.
If you would like to add a file but do not wont to compile it. Go to (for all your targets) project>build phases>compile source and take out the file that you do not want to compile.