Use Smart Client AND Web Service Factories?

Topics: CAB & Smart Client Software Factory
Jun 5, 2007 at 2:19 AM
I am beginning a Smart Client project and am just getting into the technology. I am obviously going to use the Smart Client Software Factory; however, after messing around with the Web Service Software Factory it appears to be very helpful in building out the services of the project.

Question 1: Does it make sense to use both factories?

Question 2: If it does make sense, how do you do it? After creating a new Smart Client project the solution is enabled with the Smart Client Factory options. Even if the Web service Factory is enabled in the Guidance package list none of the recipes are available. I am assuming because the correct template wasn't run during project creation...

Any Feedback would be appreciated.

Chris
Jun 5, 2007 at 8:51 AM
I've successfully used both factories, the trick is not to use them in the same Visual Studio solution.
One solution using SCSF and the other providing multiple services using WSSF. So far it has worked fine.
Jun 5, 2007 at 1:59 PM
Snoozer,

I was beginning to wonder if 2 solutions was the answer. Thanks for the post and confirming!
Jun 5, 2007 at 2:04 PM
I've used both. It would be better to have 2 solutions, but you can create one (probably the Smart Client one first) then merge the Web one into it and run the recipes from the single solution.
Jun 5, 2007 at 3:03 PM
Check this
Enable both Guidance Packages WCSF and WSSF

You can extrapolate this to SCSF to have everything in the same solution. It's a matter of metadata at the solution level.

Matias
http://staff.southworks.net/blogs/matiaswoloski
Jun 5, 2007 at 3:21 PM
I managed to unite the 2 solutions - i started with a copy of the smart client solution (save as...) and added the projects from the service solution.
After enabling the service guidance package everything seemed fine, but after a few errors, i realized you need to merge the GlobalSection(ExtensibilityGlobals) from the end of the .sln files too - something like this:
GlobalSection(ExtensibilityGlobals) = postSolution
ServiceContractNamespace = http://Project.Service.ServiceContracts/2007/05
FaultContractNamespace = http://Project.Service.FaultContracts/2007/05
DataContractNamespace = http://Project.Service.DataContracts/2007/05
UnLocked = False
Locked = True
ISWCFSolution = True
RootNamespace = Project
CommonProjectGuid = d1afe50a-f320-4643-ac32-a61b3cb1f167
ShellProjectGuid = a3883f54-9bf0-4348-9218-91e01a8ea83d
EndGlobalSection

Oh.. one other thing... some of the smart client guidance package recipes expect the Lib folder in the same directory as the solution, so if you want to have your big solution in another folder (with separate folders for client and service), you'll need to copy the Lib folder beside it.

I hope this helps.
Vlad
Jun 5, 2007 at 3:42 PM
I've read the postings here so far and I can't really figure out why you would want to put all projects (WSSF and SCSF) in the same solution.
Each WSSF service contains a lot of projects (entities, datatypes and so on). I've put each of these services in their own solution for a number of reasons.
Most of the time I work on one single service at the time, no need to load up a solution containing insert large figure of projects. Another thing is to keep the compilation time to a minimum, also its pretty easy to loose you way in all the files that are manually/auto-created.
I'm pretty comfortable in having multiple instances of VS running instead of a HUGE solution containing "all" projects.

Another thing that helped me stay out of "reference hell", is to create a post-build event and copy all the compiled assemblies to the same folder, e.g 'copy "$(TargetPath)" C:\Myproject\bin\$(ConfigurationName)' for each project in the solution. This way all other projects references the same location and its easy to deploy the project, just take all files in C:\MyProject\bin\Release.
Jun 5, 2007 at 4:45 PM

Snoozer wrote:
I've read the postings here so far and I can't really figure out why you would want to put all projects (WSSF and SCSF) in the same solution.
Each WSSF service contains a lot of projects (entities, datatypes and so on). I've put each of these services in their own solution for a number of reasons.
Most of the time I work on one single service at the time, no need to load up a solution containing insert large figure of projects. Another thing is to keep the compilation time to a minimum, also its pretty easy to loose you way in all the files that are manually/auto-created.
I'm pretty comfortable in having multiple instances of VS running instead of a HUGE solution containing "all" projects.

Another thing that helped me stay out of "reference hell", is to create a post-build event and copy all the compiled assemblies to the same folder, e.g 'copy "$(TargetPath)" C:\Myproject\bin\$(ConfigurationName)' for each project in the solution. This way all other projects references the same location and its easy to deploy the project, just take all files in C:\MyProject\bin\Release.



Of course, both are valid approaches and in the end it's the team's preference that dictates.
Reasons to merge the solutions:
- one instance of VS .NET consuming ~160Mb of memory instead of 2 instances with ~120Mb each (for a basic smart client and a service)
- you can reduce build time by using solution configurations (build only the SC or the service for example)
- reduces the risk of a broken build (Cruise Control .NET) because of a partial check-in (just the service or just the client)
- especially in the early stages, when the service interfaces and the business entities can vary a lot, i find it easier to copy things like translators and business entities from the service (generated using recipes) to the client. if they are both in the same solution.

Vlad
Jun 12, 2007 at 5:42 PM
Thanks to all for your posts. We are going to initially work with two seperate solutions due to the size of the project and also because it does seem to be a logical break; having your services developed seperately from the consuming smart client. If after developing for a while, having two solutions seems to be slowing us down we will look into migrating into a single solution.

Chris