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.
2010/10/15 Valeriu Caraulean <[email protected]>
> 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 <[email protected]>
>
>> 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.
>>
>>
>>
>>
>>
>> On 15/10/2010 7:26 PM, Valeriu Caraulean wrote:
>>
>> 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.
>>
>>
>> --
>> 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.
