tag:blogger.com,1999:blog-15136575.post8333998988597476752..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: How to structure Visual Studio solutionsMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-15136575.post-14877956512544676232013-09-05T06:37:01.938+01:002013-09-05T06:37:01.938+01:00Hi Mike,
I agree with everything you have said.
...Hi Mike,<br /><br />I agree with everything you have said.<br /><br />I argue similarly for adoption of Git in a Microsoft environment here:<br /><br />http://jenkinsheaven.blogspot.com.au/2013/08/automating-net-builds-its-not-all-about.htmlAndrew Grayhttps://www.blogger.com/profile/05937728765762464289noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-64224148796505827832013-08-30T20:54:28.013+01:002013-08-30T20:54:28.013+01:00Very interesting post. Simple and to the point. I ...Very interesting post. Simple and to the point. I agree with most of it I think, though there are a few scenarios in our company in which I end up preferring a different structure sometimes.<br /><br />For instance, we have projects with the same name, targeting different platforms (like desktop and Silverlight). In that case, I tend to group them both in the same folder, and have nested folders representing the platform, like this:<br />Company.Product.Component<br /> Silverlight<br /> Company.Product.Component.Silverlight.csproj<br /> Desktop<br />Company.Product.Component.Desktop.csproj<br /><br />Then, I create different solutions by platform, on the root. This is to enable TFS build to differentiate between the platforms based on the solution name.julealgonhttps://www.blogger.com/profile/13518771072825971877noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-74672932529704871492012-12-12T22:42:35.603+00:002012-12-12T22:42:35.603+00:00Thanks for the article. I am very new to .net dev...Thanks for the article. I am very new to .net development and am working on my first project at work.<br /><br />I appreciate your article and guidance.<br /><br />AaronAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-44388772151615781602011-07-12T14:09:42.687+01:002011-07-12T14:09:42.687+01:00So how have you found the one solution’s for multi...So how have you found the one solution’s for multiple products? I thought it might be overkill to have all the products in one solution due to size, build time and source control dependencies between versions of different products.<br /><br />We currently have three different products in three different solutions managed in SVN as three different repositories, this allows us to tag releases independent of each product. <br />Downside is that we have duplicated code. The fix for that would be to have a fourth solution with common code and reference that by file which is completely painful or merge all projects into one and loose flexibility with branching versions between products.<br /><br />What are your thoughts?seanhttps://www.blogger.com/profile/13747367230061661620noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-57812990436003922562011-03-15T09:33:13.740+00:002011-03-15T09:33:13.740+00:00Sorry Dave, I didn't answer your last question...Sorry Dave, I didn't answer your last question. Yes, this layout works fine with TFS, I've done several major projects using TFS with just this structure.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-32147174016471744062011-03-15T09:32:02.573+00:002011-03-15T09:32:02.573+00:00Hi Dave,
Just reading the P&P document, it lo...Hi Dave,<br /><br />Just reading the P&P document, it looks like they are saying the same thing as me, the folder structure is identical to my recommendation, they just don't go into detail about the solution name being 'company.product'. But if you work for a small company with a single code base that contains several products, you might well have a solution named 'company'.<br /><br />Having a single uber solution as the basis for your CI build, but smaller ones for working with visual studio, is a pattern I've often used. It's a very useful approach. It's especially useful if you have many products and a single code base.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-17950170219868855152011-03-14T02:32:16.823+00:002011-03-14T02:32:16.823+00:00Great post. Great job highlighting the "Proj...Great post. Great job highlighting the "Project Name = Assembly Name = Assembly File Name = Root Namespace = Project Folder Name" rule.<br /><br />Any 2011 tips on working with Team Foundation Server?<br /><br />In particular, I am trying to rationalize your recommendation with a Microsoft Patterns & Practices recommendation. You recommended "The solution should go in a folder with the same name as the solution (MyCompany.MyApplication) and all the projects should go in child folders of the solution folder." MSFT P&P recommends a "flat structure" in the "partitioned solution" section at http://msdn.microsoft.com/en-us/library/bb668953.aspx. I would retain your dot-rich / namespace matching naming for the .sln files.<br /><br />My head might be spinning, but I think your recommendations are for a single application and the MSFT P&P recommendation is for multiple applications with shared class libraries. I think I am just trying to extend all of your recommendations to this case of N apps sharing M class libraries.<br /><br />Does the MSFT P&P flat structure modification to your recommendations kill any of the benefits of your recommendations?<br /><br />That is, can I follow the MSFT P&P flat structure recommendation for "partitioned solutions" but still retain all the benefits of your various recommendations? Will this convergence of the 2 recommendations work? Will it work with TFS?<br /><br />Just scouting, haven't tried this yet...Davenoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-8479823639494762422011-02-15T20:08:55.749+00:002011-02-15T20:08:55.749+00:00Holy cow! You took my suggestion! (and at least on...Holy cow! You took my suggestion! (and at least one other...)<br /><br />It looks great. Thanks for the cleanup.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-46435832126332059612011-02-14T21:45:51.037+00:002011-02-14T21:45:51.037+00:00Hi Jeffrey, Thanks for kicking me to reformat this...Hi Jeffrey, Thanks for kicking me to reformat this, it's old, but still quite popular.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-27915577993997476702011-02-14T21:13:33.627+00:002011-02-14T21:13:33.627+00:00Yeah, I happen to agree with a previous commenter....Yeah, I happen to agree with a previous commenter. The post is about structuring VS, but how about structuring your blog post by using multiple paragraphs?<br /><br />It's really hard to skim and find what you want when it's packed so densely.<br /><br />Just sayin'.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-49367990920152301402011-01-12T20:08:15.104+00:002011-01-12T20:08:15.104+00:00Sure it's a great post, one of those useful an...Sure it's a great post, one of those useful and worth of reading. I was trying to figure out this dilemma of VS project org and definitely your article addresses most of my doubts. Now from then, it's a valuable foundation for "power be with you" projects organization and understand those already found in the shop where I work for. Thanks a lot!!! I hope you to continue seeing such a good posts.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-36442773144937510592009-12-07T17:33:44.966+00:002009-12-07T17:33:44.966+00:00Thanks for your post - I came across it because we...Thanks for your post - I came across it because we are surely one of those companies who do not use, let alone understand VS as well as we should. Your article did provide some sense to things, but no question, this is the worst source control monster I have ever experienced.<br /><br />I did however find it interesting and maybe a bit poetic that you recommend "dont fight the power" - in other words, just try to conform to Microsoft's 'way' of doing things.<br /><br />To me, thats like telling the Iraqi people to just 'get over it' and live with Saddam Hussein - but like them, I dont have much choice. I have to use VS even though its an overly-complex, horribly organized, poorly documented, and confoundingly clunky system. Hmmm... Just like the former Saddam!<br /><br />Someone please pray for me, or even better - just shoot me!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-59221056179766523732009-06-18T21:50:57.705+01:002009-06-18T21:50:57.705+01:00Anonymous, it was formatted. Something went horrib...Anonymous, it was formatted. Something went horribly wrong when the new blogger arrived... and I'm too lazy to fix it now :(Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-22831516372694317862009-06-11T18:54:00.786+01:002009-06-11T18:54:00.786+01:00Great comments....but it would be great if you cou...Great comments....but it would be great if you could reformat your article into logical paragraphs....make it MUCH easier to read and benefit from your pearls of wisdom. I keep getting lost in that enormous paragraph when I try to review what you've said.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-55432880553717804482008-12-13T12:09:00.000+00:002008-12-13T12:09:00.000+00:00Hi Anonymous, 100 developers? Over several years? ...Hi Anonymous, <BR/><BR/>100 developers? Over several years? That's either seriously hard core, or seriously FUBAR :) <BR/><BR/>How many million lines of code do you have? How many projects?Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-12985404845103799732008-12-13T01:39:00.000+00:002008-12-13T01:39:00.000+00:00It all works well for relatively small projects. T...It all works well for relatively small projects. Try a hundred developers over several years and many releases. Single solution approach simply does not work. Every time you modify one single file it will compile for minutes even on very good hardware. How many time do you compile per hour? I bet it's at least half a dozen. Slows development to a crawl.<BR/><BR/>No other way but to split into multiple solutions and reference assemblies from a single shared folder. :-(Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-75363563334987298042008-08-26T22:59:00.000+01:002008-08-26T22:59:00.000+01:00Solutions and projects are indeed confusing. I fo...Solutions and projects are indeed confusing. I found a good explanation at http://progproj.net/?p=76. Although it discusses VC++ it's the same concepts.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-62960249252240931842007-09-13T10:32:00.000+01:002007-09-13T10:32:00.000+01:00Paul, glad you found it useful. I'm a bit fan of T...Paul, glad you found it useful. I'm a bit fan of TortoiseSVN too. It's a shame (but understandable) why more shops are not willing to try something other than Source Safe.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-2901548942038532082007-09-13T07:42:00.000+01:002007-09-13T07:42:00.000+01:00A great article!I've printed it and I'll show it t...A great article!<BR/>I've printed it and I'll show it to my colleagues.<BR/>We use SourceSafe 6 with VS2005 and I don't like it.<BR/>At home I always use TortoiseSVN (http://tortoisesvn.tigris.org/) and it's much easier.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-18168553257536392892007-08-30T11:52:00.000+01:002007-08-30T11:52:00.000+01:00Thanks anonymous, that's a good point. Your root n...Thanks anonymous, that's a good point. Your root namespace shouldn't be something that's likely to change frequently. I guess it's a judgment call, if you work for Microsoft, then it's quite a safe bet to start your namespace with 'Microsoft', but if, as in your experience, your company is changing hands and/or name you'd probably want to use something else. But the central point still stands, you need to use a namespace that's unlikely to be duplicated elsewhere to uniquely identify your code.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-33030847029164781412007-08-29T18:29:00.000+01:002007-08-29T18:29:00.000+01:00Not so sure that CompanyName should have such a ce...Not so sure that CompanyName should have such a central place in the whole structure. The company can change its name or be bought (happened to us several times in a row) and it will be a big headache to change all file/assembly names, update installation/documentation. It's fine when it's just a namespace where we can keep whatever names we want, but exposing company name through file/assembly names may be a questionable practice (unless you are Microsoft).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-64622120980710741672007-08-10T23:53:00.000+01:002007-08-10T23:53:00.000+01:00Thanks orangeeli, I'm glad it was useful.Thanks orangeeli, I'm glad it was useful.Mike Hadlowhttps://www.blogger.com/profile/16441901713967254504noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-3301835742960338262007-08-10T16:22:00.000+01:002007-08-10T16:22:00.000+01:00Structuring solutions is always an headache but th...Structuring solutions is always an headache but thanks to your post it won't be anymore (At least not a big one...a bit smaller...lol). Cheers!^_^orangeelihttps://www.blogger.com/profile/12305276039898410372noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-31844174074863166022007-07-19T15:38:00.000+01:002007-07-19T15:38:00.000+01:00I've seen the same thing where I work. Couldn't ag...I've seen the same thing where I work. Couldn't agree with you more!Anonymousnoreply@blogger.com