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]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
