Drop 12 Lab 6 Ex2

Topics: Mobile Client Software Factory
Nov 9, 2006 at 9:46 AM
originally posted by: mccoolm

I cannot seem to build the solution in Drop 12 Lab 6 Ex 2. Has anyone else had the same problem, if so, is there a solution.

Here is the build output from the start of the problems

ompile complete -- 0 errors, 0 warnings
Mobile.SubscriptionManager -> C:\Mobile\Mobile Client Software Factory\ApplicationBlocks\SubscriptionManager\Src\bin\Debug\Microsoft.Practices.Mobile.Subscriptions.dll
------ Build started: Project: AWToGoShell, Configuration: Debug Any CPU ------
Consider app.config remapping of assembly "System.Drawing, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "1.0.5000.0" [] to Version "" C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\System.Drawing.dll to solve conflict and get rid of warning.
Consider app.config remapping of assembly "System, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "1.0.5000.0" [] to Version "" C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\System.dll to solve conflict and get rid of warning.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets : warning MSB3247: Found conflicts between different versions of the same dependent assembly.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: The "GenerateResource" task failed unexpectedly.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: System.Runtime.InteropServices.COMException (0x8000000A): The data necessary to complete this operation is not yet available. (Exception from HRESULT: 0x8000000A)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: at Microsoft.Build.Shared.ExceptionHandling.RethrowUnlessFileIO(Exception e)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: at Microsoft.Build.Tasks.GenerateResource.NeedSeparateAppDomain()
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: at Microsoft.Build.Tasks.GenerateResource.Execute()
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1616,9): error MSB4018: at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)
Done building project "AWToGoShell.csproj" -- FAILED.
Nov 9, 2006 at 9:53 AM
originally posted by: dcazzulino

First time I see it :S
Nov 9, 2006 at 10:04 AM
originally posted by: mccoolm

This is very bizzarre. I rebooted by pc and it worked !! I am see ing some really strange behaviour from VS 2005 while working through these labs.

How far away is the final release of the Mobile Composite UI Application Block ?
Nov 9, 2006 at 10:08 AM
originally posted by: dcazzulino

Em... the release has been out for months ;)

Nov 9, 2006 at 10:18 AM
originally posted by: mccoolm

I'm really confused then, I downloaded the version you mentioned, the adventureworks application is implemented quite differently from the labs.

I think what is needed for this is consistency in describing how it is to be used. If it can be implemented in many ways these have to be described and the advantages and disadvantages of each method described. This will help no end in increasing the uptake
Nov 9, 2006 at 10:23 AM
originally posted by: dcazzulino

I'm curious as to in which way you think they are quite differently.
The MSDN download comes with a full reference implementation for an end-to-end scenario.
The labs sometimes take shortcuts to make the lab easier to follow/explain, but the principles are the same.

I'd like to hear your feedback on what parts you feel are significantly inconsistent.

Nov 9, 2006 at 10:27 AM
originally posted by: mccoolm

Well one I spotted, is that one uses a WorkItem and the other uses a WorkItemController, what is the difference? It is not explained in any of the labs.

Somewhere the principles need to be described. I assumed the WorkItemController has replaced a WorkItem. It sounds as if I am wrong here
Nov 9, 2006 at 10:32 AM
originally posted by: dcazzulino

Oh, that one, yes.
They are basically the same thing, only that you use a WorkItemController to move the controller-like logic outside of a custom workitem, and put it in a new component.

You can use CAB with a controller or without. Actually CAB itself doesn't have a concept of a WorkItemController, but it's rather something you add in your project.

From my point of view, you could just use custom WorkItems and that would be fine too. The controller allows you to avoid creating custom workitems all the time, and instead just have your "use case controller" code in a separate component. It's a matter of preference, I guess, and a minor one nevertheless.

The labs do not explain it as it's not part of CAB itself.
Nov 9, 2006 at 10:41 AM
originally posted by: mccoolm

But, you see my point it is confusing. If it's not part of the CABs why is it in the labs ? Ideally I would like to see a description of the derived classes , interfaces to be implemented and methods required to be overridden to implement an application using the CAB. This would include an object model and sequence diagram explaining the the framework. THis would be more helpful.

At the minute I see a lot of code, and the labs say we are trying to to this and here's a bit of code to do it. It has no overall context. It gives the impression there is no real design behind it, i.e it has just eveolved out of something else. This is not a criticism of this particular application block, I have found this a lot elsewhere.

I think this would help a lot.
Nov 9, 2006 at 12:31 PM
originally posted by: dcazzulino

AFAIK, the WorkItemController is not used in the Labs, which is exclusively about CAB. Isn't that the case?

For more information on the design of the Composite UI block, you should take a look at the desktop version documentation. The mobile version of CAB is for the most part just a port.

About a framework/library/block evolving out of something else, that should be precisely the case always. You shouldn't be making them up out of thin air, but evolve and extract them from real applications. That's why they are always accompanied by a reference implementation application, which we use to learn/develop the blocks as we go. It allows us to detect usability issues and other problems right-away.

Documentation may be lacking, I agree, but keep in mind that getting the block done from the functional point of view was the top priority.
You can also find useful the information that comes with the Smart Client Software Factory, which is the natural continuation of the CAB.