In answer to the question about the express editions being able to
target different framework levels and profiles.
I just found this statement
In Express Editions of Visual Studio, a .NET Framework version or
profile cannot be specified when a project is created. However, you can
later retarget
On 2011-08-19, Roy Chastain wrote:
I just found this statement
In Express Editions of Visual Studio, a .NET Framework version or
profile cannot be specified when a project is created. However, you can
later retarget the project to any installed .NET Framework version.
At
On 2011-08-15, Dominik Psenner wrote:
The other big story is the support for the .NET client profiles. As I
understood it, we have to drop everything in log4net that is not
supported in a .NET 4.0 client profile (i.e. references to System.Web).
To achieve this we have at least two options
support for .NET 4.0 (need to use
a nightly build for now) and I don't think there is a target defintion
for client profiles at all - but that should be doable. I'm willing to
invest some effort here.
What I've read so far, NAnt 0.91 alpha 2 supports .NET 4.0. At least
that's what they're writing
. :-)
The main hurdle may be NAnt's limited support for .NET 4.0 (need to use
a nightly build for now) and I don't think there is a target defintion
for client profiles at all - but that should be doable. I'm willing to
invest some effort here.
What I've read so far, NAnt 0.91 alpha 2 supports .NET
On 08/15/2011 11:26 AM, Stefan Bodewig wrote:
Like I said later, I'm not convinced we need to target 4.0 at all as the
2.0 version should just work. For client profile we could use a
stripped down 2.0 version or explicitly target 3.5 (client profile).
But I may very well be missing some
On 2011-08-15, Dominik Psenner wrote:
On 08/15/2011 11:26 AM, Stefan Bodewig wrote:
Like I said later, I'm not convinced we need to target 4.0 at all as the
2.0 version should just work. For client profile we could use a
stripped down 2.0 version or explicitly target 3.5 (client profile).
:29
To: log4net-dev@logging.apache.org
Subject: Client Profiles (was Re: Open issues for 1.2.10 release)
On 2011-08-15, Dominik Psenner wrote:
The other big story is the support for the .NET client profiles. As I
understood it, we have to drop everything in log4net that is not
supported
A couple of issues
1) - There is no client profile for 2.0. 3.5 is the first version with
a client profile.
2) - There is more to building against client profiles than removing
namespaces. The references must be changed to remove the Framework DLLs
that are not part of the client profile. Again
On 2011-08-15, Roy Chastain wrote:
A couple of issues
1) - There is no client profile for 2.0. 3.5 is the first version with
a client profile.
2) - There is more to building against client profiles than removing
namespaces.
I understand both of those points.
Let's assume we target 2.0
On 2011-08-15, Roy Chastain wrote:
What I wonder is: do we really need 3.5 and 4.0 assemblies at all?
Two comments
1) - There seems to be a lot of confusion among developers about the
Frameworks. By reading the questions that have been asked on the list,
I believe that many of them do not
and 4.0 client profiles?
Assuming that the reference to the missing assembly is dropped as you
suggested, I will agree to the 3.5 client profile. (I am not saying that
it is not dropped, I just do not have knowledge of that one way or the
other.) An application targeting the 4.0 client profile
To: log4net-dev@logging.apache.org
Subject: Re: Client Profiles
On 2011-08-15, Roy Chastain wrote:
A couple of issues
1) - There is no client profile for 2.0. 3.5 is the first version
with a client profile.
2) - There is more to building against client profiles than removing
namespaces.
I
add conditional compilation on a CLIENT_PROFILE that
removes all System.Web references and target 2.0 again but this time
with the symbol set. Shouldn't the resulting assembly work for the
3.5 and 4.0 client profiles?
Assuming that the reference to the missing assembly is dropped as you
14 matches
Mail list logo
