Silverlight target, how are you doing it?
4 views
Skip to first unread message
Valeriu Caraulean
Oct 13, 2010, 4:25:45 AM10/13/10
to castle-pro...@googlegroups.com
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
Krzysztof Koźmic
Oct 13, 2010, 5:05:20 AM10/13/10
to castle-pro...@googlegroups.com
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
> --
> 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
> castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
Valeriu Caraulean
Oct 13, 2010, 10:57:23 AM10/13/10
to castle-pro...@googlegroups.com
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.
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 <krzyszto...@gmail.com>
Paul Stovell
Oct 14, 2010, 10:08:05 PM10/14/10
to Castle Project Development List
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 <caraul...@gmail.com> 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...>
> .
> >> castle-project-d...@googlegroups.com<castle-project-devel%2Bun subs...@googlegroups.com>
> >> .
> > .
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 <caraul...@gmail.com> 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
> .
>
> 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 <krzysztof.koz...@gmail.com>
> 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.
>
> >> .
> >> 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 castle-pro...@googlegroups.com
> > .
> >>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 castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to
> > castle-project-d...@googlegroups.com<castle-project-devel%2Bun subs...@googlegroups.com>
> > .
Krzysztof Koźmic
Oct 14, 2010, 10:22:41 PM10/14/10
to castle-pro...@googlegroups.com
Valeriu,
We've already tried keeping two versions of solution - one for .NET one for Silverlight and it didn't work. The problem was that keeping them in sync with regard to added/removed/renamed files and changes to the buildscripts/.scproj files was just a major PITA.
That's why we went with single solution+multitargetting approach and it works well mostly.
I'm wondering - perhaps we would be able to modify the .sln/scproj files so that Visual Studio can consume them, so that by switching build configuration we'd be able to switch target framework version in Visual Studio as well?
Would that be possible/feasable?
We've already tried keeping two versions of solution - one for .NET one for Silverlight and it didn't work. The problem was that keeping them in sync with regard to added/removed/renamed files and changes to the buildscripts/.scproj files was just a major PITA.
That's why we went with single solution+multitargetting approach and it works well mostly.
I'm wondering - perhaps we would be able to modify the .sln/scproj files so that Visual Studio can consume them, so that by switching build configuration we'd be able to switch target framework version in Visual Studio as well?
Would that be possible/feasable?
Valeriu Caraulean
Oct 15, 2010, 5:19:33 AM10/15/10
to castle-pro...@googlegroups.com
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?
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
Valeriu Caraulean
Oct 15, 2010, 5:26:40 AM10/15/10
to castle-pro...@googlegroups.com
The Visual Studion extension called Project Linker is doing the sync for you. Look at my response to Paul.
What about modification of solution/project files - that's an interesting idea. I'll think about it more. It may be possible to locate differences and include/exclude them automatically.
We're using in some of our project conditional fragments in our msbuild files. An example:
<Choose>
<When Condition="$(PROCESSOR_ARCHITECTURE) == 'AMD64' Or $(PROCESSOR_ARCHITEW6432) == 'AMD64'">
<ItemGroup>
<Reference Include="System.Data.SQLite, Version=1.0.65.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\Lib\x64\System.Data.SQLite.DLL</HintPath>
</Reference>
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
<Reference Include="System.Data.SQLite, Version=1.0.65.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\Lib\x86\System.Data.SQLite.DLL</HintPath>
</Reference>
</ItemGroup>
</Otherwise>
</Choose>
Will think more about it...
2010/10/15 Krzysztof Koźmic <krzyszto...@gmail.com>
Krzysztof Koźmic
Oct 15, 2010, 5:31:40 AM10/15/10
to castle-pro...@googlegroups.com
We're already using heavily modified .scproj files. Take a look. I
think trying to approach it from this angle (so that we stick to a
single solution) is the most promissing approach.
I'm strongly against having two parallel solutions.
I'm strongly against having two parallel solutions.
Valeriu Caraulean
Oct 15, 2010, 5:47:59 AM10/15/10
to castle-pro...@googlegroups.com
OK, I've got your point.
I'll be looking at project files if it's possible to improve something without messing too much things...
And, at the end of the day, nothing is impeding me keeping a dedicated Silverlight solution & projects in my own fork and generating patches/pull requests from it. So that everybody will be happy...
Thanks for your attention, Krzysztof.
Cheers
2010/10/15 Krzysztof Koźmic <krzyszto...@gmail.com>
Roelof Blom
Oct 15, 2010, 6:58:39 AM10/15/10
to castle-pro...@googlegroups.com
It's possibly by manually editing the XML in the project file to define TargetFrameworkProperty in each configuration-specific property group instead of the global property group.
Currently our projects look something like this:
<PropertyGroup>
<TargetFrameworkVersion>Some version</TargetFrameworkVersion>
</PropertyGroup>
And they should look something like this when creating per framework configurations.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'v4.0 Debug|AnyCPU' ">
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'v3.5 Debug|AnyCPU' ">
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'SL4 Debug|AnyCPU' ">
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
Combined with the conditional references, like Valeriu described for the SQLite x64/x86, this may all work.
Visual Studio however has no native support for these two modifications(TargetFrameworkVersion per configuration and conditional references), for instance it will issue warnings about missing references but the projects compile fine though. You'll also lose the ability to add references with Visual Studio. And the Application tab on the project properties dialog will not tell the correct framework version because that tab is not per configuration.
-- Roelof.
Krzysztof Koźmic
Oct 15, 2010, 7:05:52 AM10/15/10
to castle-pro...@googlegroups.com
I don't care about missing references warnings and I couldn't care
less about inability to add references. We do it once in a blue moon
or even less frequently.
In other words - looks promissing :-)
Krzysztof
In other words - looks promissing :-)
Krzysztof
Roelof Blom
Oct 19, 2010, 3:17:32 AM10/19/10
to castle-pro...@googlegroups.com
The build configurations for all platforms are now in the .csproj files. Currently we have
- NET40 Debug and Release
- NET35 Debug and Release
- SL30 Debug and Release
- SL40 Debug and Release
The primary advantages being: conditional compilation symbols can be defined in csproj now, getting syntax colouring for conditional compilation to the specific platform, and a simpler build script.
The Silverlight builds are also working again.
Sadly, Visual Studio cannot be coerced to build any other framework than the default specified in the application properties tab for the project, meaning that SL builds need to created from the command line.
Krzysztof Koźmic
Oct 19, 2010, 3:20:28 AM10/19/10
to castle-pro...@googlegroups.com
Well done. Can I have same thing for Windsor?
sent from my HTC Desire
On 19/10/2010 5:17 PM, "Roelof Blom" <roelo...@gmail.com> wrote:
The build configurations for all platforms are now in the .csproj files. Currently we have- NET40 Debug and Release- NET35 Debug and Release- SL30 Debug and Release- SL40 Debug and ReleaseThe primary advantages being: conditional compilation symbols can be defined in csproj now, getting syntax colouring for conditional compilation to the specific platform, and a simpler build script.The Silverlight builds are also working again.Sadly, Visual Studio cannot be coerced to build any other framework than the default specified in the application properties tab for the project, meaning that SL builds need to created from the command line.
-- Roelof.
2010/10/15 Krzysztof Koźmic <krzyszto...@gmail.com>
>
> I don't care about missing references...--
You received this message because you are subscribed to the Google Groups "Castle Project Develo...
Roelof Blom
Oct 19, 2010, 3:38:43 AM10/19/10
to castle-pro...@googlegroups.com
Yeah, I'll tweak the script a bit more and then give Windsor the same love.
2010/10/19 Krzysztof Koźmic <krzyszto...@gmail.com>
--
Krzysztof Koźmic
Oct 19, 2010, 3:40:30 AM10/19/10
to castle-pro...@googlegroups.com
Cheers. Is it possible to reuse the work you do once so that we don't have to manually update each project?
sent from my HTC Desire
On 19/10/2010 5:38 PM, "Roelof Blom" <roelo...@gmail.com> wrote:
Yeah, I'll tweak the script a bit more and then give Windsor the same love.
>
> Well done. Can I have same thing for Windsor?
>
> sent from my HTC Desire
>>
>> On 19/10/2010 5:...
--> You received this message because you are subscribed to the Google Groups "Castle Project Developm...
--
You received this message because you are subscribed to the Google Groups "Castle Project Deve...
Reply all
Reply to author
Forward
0 new messages