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 <[email protected]>
> 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?
>
>
> On 14/10/2010 12:57 AM, Valeriu Caraulean 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-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 <[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]>
>>> .
>>> 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.
>
>
> --
> 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.
