In my current project we have a very big solution with F#-project. I'm talking really big here . Its 70 F# projects (480 .fs files) and 4 C# projects.
As you probably guess this is starting to be a problem. First of all it takes forever to manage in Visual Studio. But then it also takes too long to build - last time I checked it took ca 3 minutes on my machine.
I know that there are (unsupported?) ways to organize F#-files in Folders in your projects but given the size of the solution I dread going through it and do that manually. Also we want to be pretty sure that it will improve the build time.
So, now my question - will merging into fewer projects decrease build time? Say that we get it down to 5-10 projects instead of 70 as of today.
If not - what can we do instead? How do you manage projects of this size?
I can't speak for large F# solutions but I've done this with large C# solutions, and seen build times drop massively. e.g. One solution had ~100 projects which we reduced to ~20 and build times dropped from > 10 minutes to < 5 minutes.
The gain came mainly from reducing dependency checking and the number of times files were copied from one project's build output folder to another.
If F# compilation is very slow it may be due to NGEN not having run after recent .net framework updates. See these two stackoverflow questions: f# compiling too slow and F# is running very slow since last round of Windows updates for more information
Tried SSD & RAM drives doesn't do much.
Dependencies between projects might prevent you from gaining anything from increasing the number of concurrent build.
I'm a bit surprised you have 480 .fs files in 70 projects... that amounts to about 6-7 files per project which isn't much. It might be worth looking over that anyway even if it's not for performance reason - one can have (will?) design issues either way. But build time seems to be consistent with the number of files (or LOCs) per project so you may not squeeze as much as you'd want there.
I personally lost the habit of cleaning and rebuilding every time for that reason.
Edit: Found a related note in Expert F# which I thought was worth mentionning:
.NET assemblies often contain a large amount of code. For example, a single assembly may contain as
many as 50 or 100 F# source code files. Having many small assemblies may seem tempting, such as to improve
compilation times during development, but can lead to difficulties when you’re managing updates and can be
confusing to end users. Large assemblies are easier to version: you have to update only one component, and you
can package multiple updates into a single new version of the DLL
Related
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
Our issue is as follows:
solution takes a while to start up when running
after hitting run and while monitoring the Output window, constant work done is loading project related files from .net temp dir
this really takes a while
this is a Web Forms app with quite a large set of UI controls/pages and about 250 DLL/component dependencies
references are added as DLL refs and not proj refs
Given the information above, what would be some of the suggestions to speed up solution startup at run times?
Frankly, there may not be a whole lot you can do. But be sure to disable antivirus scanning of the project, as scanning each file as it loads will slow the machine to a crawl.
There are a few other tips floating around, but I'm hoping performance will be improved via an update of some sort.
Lots of links and things to try are here:
http://www.experts-exchange.com/blogs/TheLearnedOne/B_4684-Visual-Studio-NET-2010-Performance.html
This is a follow-on post to our previous post (Help Structuring VS2010 Solutions/Projects and TFS2010).
We have a few questions regarding how to structure our VS2010 solutions and projects for best organization, as well as to save in and use TFS2010.
Currently, our code is structured something like:
/OverallAppName
OverallAppName.sln
-/Client
- -/WindowsFormsProject1
WindowsFormsProject1.sln
- -/WindowsFormsProject2
WindowsFormsProject2.sln
-/Components
- -/ClassLibrary1 (common library referenced by other projects)
ClassLibrary1.sln
- -/ClassLibrary2
ClassLibrary2.sln
- -/ClassLibrary3
ClassLibrary3.sln
- -/ClassLibrary4
ClassLibrary4.sln
- -/ClassLibrary5
ClassLibrary5.sln
-/Server
- -/WindowsServiceProject1
WindowsServiceProject1.sln
- -/WindowsServiceProject2
WindowsServiceProject2.sln
- -/WebProject1
WebProject1.sln
- -/WebProject2
WebProject2.sln
Since, right now, we’re in the process of moving from VSS to TFS2010, we’re wanting to structure all our solutions/projects to be most efficient, most logical, easiest to maintain, easiest to reference, and easiest to use with and build in TFS2010, and we’re needing some advice on the “best” way to structure everything with a partitioned solution model.
Any suggestions????? How can we structure all these different types of VS2010 projects into a logical structure that separate groups can work on individual pieces (not the entire solution), we can still have project references, we can stored in TFS2010 and build and branch in there, and follow “recommended best practices”?
Thanks.
(Sorry, I'm not sure the formatting came out very good.)
While I admire your commitment to trying to keep everything as one large solution, I think this is going to defeat some of the best features TFS has to offer in the realm of automated builds by sticking to this.
The reason I say that is because you can use builds triggered by check-in to immediately build the code to prove it works (or better yet, use a Gated check-in). The usefulness of these builds are inversely proportional to the time they take to run. So if you have a massive solution that takes 20 minutes to build then it's going to take away from the advantages of those types of builds. If however you had several smaller solutions that took about 5 minutes each then you'll only get the modified solutions building on check-in and know the results sooner.
From what you've listed above I'd be inclined to have a solution for each set of artefacts that can be released separately. In your example that's probably one for each of the clients, one for each of the web applications and one for all of the common libraries.
Folder structure wise it'll not be much different to what you have above (assuming I'm interpreting it correctly)
/OverallApplication
/Clients
/Client1
-Client1.sln
/Client1Project1
-Client1Project1.csproj
/Client1Project2
-Client1Project1.csproj
...
...
/Components
-Components.sln
/ClassLibrary1
-ClassLibrary1.csproj
/ClassLibrary2
-ClassLibrary2.csproj
...
/Server
/WebApp1
-WebApp1.sln
/WebApp1Project1
-WebApp1Project1.csproj
/WebApp1Project2
-WebApp1Project1.csproj
...
...
/CodeSigningKey
-KeyPair.snk
/ReferencedAssemblies
/Manufacturer1
-Manufacturer1Assembly1.dll
...
...
The common libraries can still be added as project references in the server and client solutions. I've introduced a few new folders for common items such as the code signing key and 3rd party assemblies that are referenced (such as the Enterprise Library).
On top of that you'll want to employ a branching strategy of some kind to keep Main, Dev and Release code branches separate. I recommend a little light reading of the ALM Rangers branching guide on codeplex for that.
http://vsarbranchingguide.codeplex.com/releases
We are working on a big application, comprising around 100 projects (40 views, 40 controllers/models, 20 Utilities libraries). We have outsourced the bulk of the work and the deliverables come in fairly randomly.
When we get a deliverable (a project), we need to run FxCop, StyleCop, the associated unit-tests, etc, etc. before committing it to source control. To make this easier, we have mandated that every project has a solution file. This allows us to simply run an automated script on the solution file which tests it before checking it in.
My question is "Can you think of any drawbacks to having 1 solution for each project?".
Drawbacks we have already discussed include:
Additional maintenance required by developers. This doesn't bother us as we have outsourced development on a fixed-price contract.
SourceSafe bindings in solution file. This could have been a huge issue, but luckily we migrated to TFS about a year ago.
We're in a similar boat with about 200 projects, many of them common use, accross our various solutions of varying sizes.
While a disadvantage is load time, one advantage is debugging - i.e. if your code is calling into other assemblies, then it's nice to have everything in the same solution.
Also, we do keep our unit and integration tests along with our core project (DLL or EXE) all in the same solution, so even on a bare bones template we have at least three per solution.
Ultimately I'd say the largest advantage of a common solution boils down to cross-project debugging, IMO. - But I would never just toss them together unless there was at least this, or some other compelling reason.
On a side note - we do not allow a project without a solution for the reasons you noted above (running FxCop, etc.) plus Continuous Integration. One disadvantage of a large solution with several projects is build time - but it does help to know if messing with a component ended up breaking an unrelated solution/project.
We did discover one drawback in the end. All our projects are in Visual Studio 2008. If we want to upgrade one project to Visual Studio 2010, we realised we would almost certainly need to upgrade every other project (as they are all, directly or indirectly, either dependent on, or depended on, each other).
here is the situation.
I am using visual studio 2005.
the solution contains lots of projects, 34 projects in all, and the start up projects depends on others.
then in linking part, it'll wait a long time before the real linking starts.
I am pretty sure it's because of too many projects depended, as when I use a solution with 10 of the 34 projects(keep other projects as headers&libs), it'll start instantly.
so any one has any idea that I can reduce the waiting time?
thx.
If 10 is fast and 34 is incredibly slow, you might try adding projects one-at-a-time to the 10-project solution until it gets slow. There may be one particular project that causes the slowness.
You could turn off "Whole Program Optimization", that should speed up the linking for you. Then you could use it in your final stages of release.
Enable the option in link-general-enable Incremental linking
Or
Unity Build
will useful for you