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
On 15/10/2010 8:58 PM, Roelof Blom wrote:
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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
