My team is developing WCF services in Visual Studio 2008 SP1 with the Service Factory Modeling Edition. The problem is that we have so many services to develop and we've put everything in the same solution.
250 projects later, the solution barely loads and adding to it is nearly impossible. We thought it would be good to split out every service into its own solution, but the service factory stuff effectively prevents us from doing that.
We are generating code from our model project into our other projects, but if we try to use multiple solutions, we can't reference the model project because it can't maintain the project mappings it needs in order to generate to the proper location. And we use a couple shared data contracts in our Model Project, so splitting the model project up doesn't seem to make sense either.
We have so many projects now that we can't really turn back and not use the service factory method of doing everything.
What should we do?
At this point you should break up your 250 projects into groups and create a solution for each of them. My recomendation is to use ~25 projects per solution. Use these mini-solutions for your day to day editting.
It is still possible to do a full build of the overall solution via msbuild and the command line. But VS was not meant to handle so many projects at the sametime.
I'm surprised to hear you say this. I used the Service Factory in my previous job, and we created a separate solution for each suite of services. In each solution, we created one or more models in the model project.
I recommend that you experiment by creating a couple of new SF solutions, adding a couple of models and generating code. See if that causes any problems.
Have you discussed this or created an issue on CodePlex?
I agree with John Saunders. Keep them small. Also, keep a Continuous Integration env running to keep track of your mess-ups during development.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I am very new to BizTalk. I have been asked to create a application in BizTalk. I am facing some design level challenges.
Following are some of them:
Best approach in creating a project
How to crate BizTalk solution. Means how to create projects. Do we need to create different projects for Maps/Orchestation/pipelines and references. Which is the best approach to develop a project?
Can we check in a BizTalk project in TFS
How multiple people can work on a single BizTalk solution? Can it be checked in in TFS and multiple people can take it and work on it? How merging will work?
Code review
Is there any way to review a BizTalk package? What are the best practices?
This is very subjective. I always establish that there is a 1-1-1 App/Solution/Deployment unit. Meaning an Visual Studio Solution should be deployable/undeployable on it's own. No references to other Solutions.
I do not create separate Projects for Schema/Maps/Orchestrations/Pipelines, there's no benefit unless the App/Solution is large...say more than 10 Message Types. Then, it's OK to separate.
Yes, of course. Any number of Devs can contribute to a Solution. The only thing you can't do is Merge BizTalk Artifacts. The Xml definitions are confusing to the Merge tool.
Code Review should be done just like any other project.
We have a website application that stores data and pictures for a specific customer. We are about to release the same application for use by another customer. The second application will eventually be customized for the second customer. Eventually we hope to have several customers using their own versions of the application.
We are using ASP.NET in Visual Studio 2012. Should we:
clone the existing application and maintain separate code bases?
add a project to the existing solution for the new customer?
We have searched for an answer to but this seems to be a rare situation.
Thanks.
I dont think its rare at all. SAP and Maximo use this a a businiess model. Same core but each package customized to the clients specifications. I have done this (on a much much smaller scale) with some of the programs that we have.
We always start a new project rather than just copy the old. No telling what is in the old one that references the old client. Sort of embarasing when an About window that you forgot about is for someone elses company.
All the code, forms, reports that are customizeable should be in the project for that customer. All of the code, forms, reports that are standard should be in a library.
It really depends on the scope of the application. I've had to do this internally with the company I'm working for; I wrote one solution for one company, then the sister company found out and wanted the same and had to implement it there.
I had a fairly small project to work on, so it was easy to make it universal (while also keeping things rooting from the same code base). All i did was:
break out the unique setting [page title?] using appSettings or similar.
add a new configuration to your solution. Then take advantage of the *.config migrations to:
set connectionStrings
specify appSettings values
When it comes to unique business logic, I had the luxury of using the *.config migrations (most of the data I gathered came from WCF endpoints of services local to the company)--so I lucked out. However, you could make generic interfaces within the app then break out implementation for each company in to separate libraries.
We have Team Foundation Server 2008 deployed as our source control management system. A team that is responsible for multiple products is asking for all their products to be put under a single TFS project. Their reason is because the products are all in a similar domain.
Here are my reasons against:
The workspace mappings will get weird, since projects will be mapped to subfolders
Continuous Integration may be a problem, since a single project can't be referenced
Tracking history of source control activity could be problematic
This just feels like an overall bad idea, but I would like some concrete reasons against it. If I'm completely off-base and this is a good approach to take, I'd like to hear that as well.
What are the pros/cons?
I have experience storing multiple Visual Studio Solutions (seperate products) under one TFS Team Project in both TFS2008 and TFS2010. Here is my take.
In both versions we create a folder for the Product, then a folder for the branches (Main, etc.) This makes it easy to see what product we are working on, and we can see the history of the product seperate from other products. Continuous integration works just fine with multiple build definitions, one for each product. We only create one workspace mapping for the entire TFS Team Project.
The shortfall in TFS2008 is that it can be difficult to manage work items for each Product. In TFS2008 the work items apply to the entire Team Project and it is not as easy as it should be to figure out which work item belongs to which product.
In TFS2010 the work items have an Areas and Iterations section. We use the Area to define the Product. So each Work Item gets an Area that matches the Product name. This has worked very well for us.
If you are not using work items heavily in TFS2008 than I don't think you should avoid putting multiple Products in one TFS Team Project, certinally not for the reasons you listed above.
Using one Team Project does haves some advantages:
1. There is ony one Team Project to manage and there is only one Share Point site.
2. You can see history across the entire Team Project easily.
My thoughts:
If there are assemblies shared amongst the projects, it makes sense to lump them together, otherwise you will run into the same problems that many people have discussed here, on how to handle shared assemblies.
You shouldn't encounter any problems with workspace mappings. Within our organization, we simply map $/ to a folder and go from there. Otherwise you could very easily map individual source control folders to different areas on disk. The only recommendation I would have is to put that mapping in a batch file, so that new members can run the batch and be consistent.
The only thing that you might lose out on a bit by lumping these all together is quick and easy reporting. If everything is in its own Team Project, the built-in reporting works "out of the box." If you put things together, you'll need to set up additional areas and iterations in order to do the reporting and tracking.
In our organization we have upward of 15 separate team projects, but every single one of them has more than one "product" underneath. We've been running this way for two years and really haven't had any problem with it, with the exception of the reporting.
Using a single Team Project for more than one software is a perfectly acceptable solution if you don't use separate templates for them. Martin Hinshelwood has a detailed blog post on the subject.
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
Following SO thread shows Managing DLL references in multiple projects across different solutions. Additionally I want to know how to manage the version control for these dependency DLLs ?
Should the DLL (which is published to other external projects) be committed too, every time code change happens ?
Team Development with TFS Guide (Final Release)
This guide has proven to be invaluable to my team. They describe several scenarios and what the pros and cons are of each. For anyone managing a TFS environment this is a must read.
With regards to the DLL's from external projects. We will keep a copy of the source in TFS if we can get access to the source some times, use your best judgement. We keep a copy of the DLL in source control always. The DLL goes into a "SharedBinaries" folder next to source code so that they can be branched together.
It is critical that you be able to branch these DLL's along with source. It is also critical that they be in TFS so that you can do an automated build with little or no build machine configuration. My own personal goal while managing TFS is to be ready for a new developer to join the team and with a single get of source code be able to execute a successful build for local debugging.
EDIT: Different department builds DLL
Like all good IT answers I have to start with "it depends". If the other department is truly segregated from your department and you have little or no knowledge of what they are working or when they will be working on it. If they just occasionally tell you that they have done some things and you should now incorporate the changes then I would lean towards the DLL being committed to the repository every time that the department consuming it wants to change it.
If on the other hand we are really just talking about different teams in the same department where there is lots of cross talk and water cooler communication then I would expect that you could making something else work with just some project references.
It sounds to me like it is the former and not the latter situation that you find yourself in today. I would try to get the department that is creating the shared code to "release" the shared code like Microsoft releases the .NET Framework. Get them to just build the API and give you some DLL's and some documentation. Then the groups that are incorporating those DLL's into there products can check them in separately into a repository of there own control and isolate themselves from code churn while the department working on the these reused DLL's can work on the next version of them.
You should take this all with a grain of salt. This is just one guy rambling on about what might be a good idea. There are many more ways to solve these problems and they are all correct given different circumstances. If you are asking 5 people and you get 5 different responses I wouldn't be surprised.