3

When I build my solution using MSBuild 4 it compiles successfully:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MySolution.sln

Build succeeded.

0 Warning(s)
0 Error(s)

But when I try to do the same using MSBuild 3.5 I get the following error, even though the source is the same and I am using the same libraries and the same version of the .NET Framework.

C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe MySolution.sln

error CS1501: No overload for method 'InitializeClientContextFromStringSid' takes '2' arguments

error CS1501: No overload for method 'GetRoles' takes '0' arguments

The error that I get is related to Authorization Manager (AzMan).

The method 'InitializeClientContextFromStringSid' in the first error belongs to the public interface IAzApplication, a member of Microsoft.Interop.Security.AzRoles.

The method 'GetRoles' in the second error belongs to the public interface IAzClientContext, also a member of Microsoft.Interop.Security.AzRoles.

I am using the methods in the following way:

var clientContext = _azApplication.InitializeClientContextFromStringSid(member, 0);

where the variable member is a string containing the Windows Active Directory SID from an user and _azApplication is of type IAzApplication.

clientContext.GetRoles()

where clientContext is of type IAzClientContext.

Why does my solution builds with MSBuild 4 but not with MSBuild 3.5 even though I'm targeting the same version of the .NET Framework (3.5)?

Community
  • 1
  • 1
macrobug
  • 666
  • 6
  • 16

1 Answers1

6

It looks like InitializeClientContextFromStringSid has an optional parameter in the specification. Though MSBuild in .Net Framework 4.0 supports the use of optional parameters in C# by allowing you to leave them out of the function call, previous versions of the MSBuild do not support this approach. So you must to supply the parameter even if it's not being used when building with older version of the Framework.

HRESULT InitializeClientContextFromStringSid(
  [in]            BSTR SidString,
  [in]            LONG lOptions,
  [in, optional]  VARIANT varReserved,
  [out]           IAzClientContext **ppClientContext
);

The same issue is happening with the GetRolesmethod.

From my understanding, the reason you can build using the 4.0 version of MSBuild and target 3.5 Framework is that the CLR already supported the use of Optional parameters, for example VB.NET has always supported them. However, when using MSBuild 3.5, it is going to use the older rules/specification that did not allow support for Optional parameters in C# and thus will give you build errors.

Goronmon
  • 121
  • 8
  • Hi Goronmon, thank you for trying to help me. But the problem is I am not using .NET 4.0. I am using .NET 3.5 in both cases. – macrobug Nov 30 '10 at 15:20
  • 1
    If you are using MSBuild under 4.0 it is going to compile under that specification. Try using dummy variables for the optional parameters for those two functions and see if it them compiles using the 3.5 version of MSBuild. – Goronmon Nov 30 '10 at 15:30
  • Yes, it compiles. But why does it behaves different depending of the MSBuild version that I use if the Target Framework is set to 3.5. I thought it would compile exactly the same regardless of the version of MSBuild that I use. Unless there is something that I am missing. – macrobug Nov 30 '10 at 15:49
  • 1
    Support for using Optional parameters in C# was added with the .Net Framework 4.0. However, optional parameters were technically already supported in VB.net so you can target Framework 3.5 and still use optional parameters because the CLR always supported them. However, the MSBuild in 3.5 is going to use the old rules/specification for C# which doesn't support optional parameters correctly and thus give you compile errors. – Goronmon Nov 30 '10 at 15:57
  • So, do you think it is a bug in MSBuild 4 that allows us to use optional parameters with C# in .NET 3.5? – macrobug Nov 30 '10 at 16:50
  • 1
    It's not a bug. Like I said, the .NET Framework has technically always supported optional parameters, for example with VB.NET. However, the previous compilers for C# did not because it was not part of the specification. This changed with 4.0, so the 4.0 version of MSBuild will not produce errors when using optional parameters while the previous versions like 3.5 will. Once the compiled, the CLR has no problem dealing with the optional parameters since it has always supported them, it's just the compiler itself that did not. – Goronmon Nov 30 '10 at 16:54