Paul, Thank for sharing your experience here. I don't have too much experience with Silverlight nor maintaining multi-targeted solutions so for me it's interesting to see how other people are working on it. But have you used ProjectLinker, or managed linked files manually?
Back to the Castle.Core & development workflow. I'm thinking about keeping two solutions: - Castle.Core - containing only projects targeting .NET - Castle.Core-SL - containing projects with .NET target AND "linked" projects for Silverlight. Then workflows, depending on which solution is used: - Most of developers will work on Castle.Core project. They will do it as before, without even thinking about Silverlight. Doing big refactorings without the fear to break something in other targets. Building and running tests as before. - Those of developers who "don't mind" working with Castle.Core-SL *and will have set up ProjectLinker* will have nothing more to care about - ProjectLinker will sync links to files automatically. Renames, Add/Remove files - you just don't care, you have single solution compiling same source files for different targets. All "#if Silverlight" are hidden/expanded automatically (by R#). There is one question left, what if somebody have worked with Casle.Core solution and modified project at file level (add/delete/rename) so that Castle.Core.SL will broke and it would not build. In this case, later on same developer or somebody else that care about SL will open Castle.Core-SL solution and will "resync" SL projects with .NET ones using ProjectLinker. With current version of PL in order to re-sync you have to "Exclude from Project" all source file and folders and then "Include in Project" them back. This last step is OK if you do it carefully, but still tedious and error prone. To improve that, I've picked sources of ProjectLinker extension and will dig into to look if I can add a new feature to it "Re-Sync Links". So that if projects will come out of sync, you'll open SL solution and will choose from VS menu "Project->Re-Sync Links" and it will do the work automatically. What do you think, guys? On Fri, Oct 15, 2010 at 4:08 AM, Paul Stovell <[email protected]> wrote: > This is a little OT but Krzysztof asked me to share my experiences > with this style of working with both platforms. > > For Magellan I set up a Silverlight project with files linked to the > original WPF files. It was similar to what you describe. > > The major problem I had with it related to my personal development > workflow. Sometimes I decide to add a new feature, so I bash it out > quickly in the WPF projects. But I'd keep having to stop and fix the > Silverlight project, which interrupted my flow. I was experimenting > with ideas like "How do I make sure this scheduler is garbage > collected", and I'd keep having to stop and fix compile bugs in > Silverlight any time I tried to hit F5. > > I had better experiences with Bindable LINQ, where my solution was to > use the same csproj, but to just call Silverlight's csc.exe *.cs from > the command line occasionally (since it was just a plain C# project). > What was nice about this is it meant I could focus on implementing a > feature for WPF ("lets see what an observable GroupBy would look > like"), and then a few hours later switch my focus to "how do I make > it work in Silverlight?" > > There's no doubt the linker approach works, but for me it comes down > to your workflow - are you happy to keep paying the "Silverlight tax" > every time you try to compile/run tests, or would you rather focus on > implementing a feature and then focus on Silverlight once it's > complete? If you're deep into implementing generics support in Dynamic > Proxy, I'm not sure you'd want to stop and add #ifdef's or custom > files for Silverlight every time you try to compile. > > Paul > > > On Oct 14, 12:57 am, Valeriu Caraulean <[email protected]> wrote: > > I've took some time and created Silverlight-specific solution & projects > > that are available to work on within Visual Studio. > > Everything compiles, all tests are green (both targets, NET4 & SL). A > > cleanup & removing some duplication at project/solution level is > required. > > Also, build scripts should be reviewed. > > > > I've took traditional way for multi-targeting, where a second project > > (Silverlight) is created and all source files are linked to original > > project. To make things a bit more automated, I've used Project Linker > tool. > > I've posted detailed description of the process in my blog - > Multi-targeting > > with Project Linker by example: Castle.Core for Silverlight > > 4< > http://blog.caraulean.com/2010/10/13/multi-targeting-with-project-lin...> > > . > > > > I've committed all changes to my Castle.Core fork on GitHub: > http://github.com/vcaraulean/Castle.Core > > Solution that contains new projects: > > Castle.Core-SL.sln > > > > I'll be very glad if somebody will review my commits. Any feedback and > > comments are welcome. > > > > 2010/10/13 Krzysztof Koźmic <[email protected]> > > > > > > > > > Hi Valeriu, > > > > > Yes, that's how I do Silverlight build - from command line with tests. > That > > > hasn't really been a problem for me thus far but if you have a way to > make > > > it easier to work with Silverlight target in Visual Studio that would > > > certainly be beneficial for anyone who would want to do so. > > > > > Perhaps Roelof can better answer this. > > > > > Cheers, > > > Krzysztof > > > > > On 13/10/2010 6:25 PM, Valeriu Caraulean wrote: > > > > >> Hi > > > > >> I'm interesting how people are working with sources when working with > > >> Silverlight target. > > >> From what I've seen, there is no way actually to have a > solution/project > > >> in VS targeted for SL4. The binaries for Silverlight can be built only > from > > >> command line. Tests can be run only from command line. Is that true? > > > > >> I'm asking this because the Silverlight 4 build is broken, I'll try to > fix > > >> it. Also, I want to enable few tests for DictionaryAdapter that are > ignored > > >> at this moment for SL. > > > > >> Thanks > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Castle Project Development List" group. > > >> To post to this group, send email to > > >> [email protected]. > > >> To unsubscribe from this group, send email to > > >> [email protected]<castle-project-devel%[email protected]><castle-project-devel%2Bun > [email protected]> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/castle-project-devel?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Castle Project Development List" group. > > > To post to this group, send email to > [email protected] > > > . > > > To unsubscribe from this group, send email to > > > [email protected]<castle-project-devel%[email protected]><castle-project-devel%2Bun > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/castle-project-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
