Ranorex 3.2.2 Compile Error

Bug reports.
beau.styne
Posts: 3
Joined: Thu Mar 01, 2012 5:32 pm

Ranorex 3.2.2 Compile Error

Post by beau.styne » Thu Mar 01, 2012 6:28 pm

Support Team:
OS - Windows 7 64-bit
Ranorex 3.2.2
Common.rxsln is using AnyProcessor as Target CPU and the Platform is AnyCPU

Previously to moving up to 3.2.2, we were using 3.1.3. In the 3.1.3 build, the issues we ran into involved the 64 bit debugger error and version 3.2.2 solved that; however, compiling issues arose where they had previously not. The code that would not compile in 3.2.2 was written in .NET 3.5 framework. We received the following error "Default parameter specifiers are not permitted." in Ranorex, but when compiled in Visual Studio 2010, the build solution was successful. When using 3.1.3, VS2010 had already converted the Ranorex build, but, when using 3.2.2, anytime 3.2.2 touches the solution VS2010 needs to re-convert the project.

Snapshots in Zip file:
3_2_2bug0 - shows the error in Ranorex due to "Default parameter specifiers are not permitted." error.
3_2_2bug1 - shows the enum region where above parameter options are derived from
3_2_2bug2 - shows the VS2010 successful build of the same solution

Thank you for your consideration
Attachments
Ranorex3_2_2bug.zip
3_2_2bug0 - Screenshot of error found
3_2_2bug1 - parameter options derived
3_2_2bug2 - VS2010 build
(3.14 MiB) Downloaded 201 times

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Ranorex 3.2.2 Compile Error

Post by Support Team » Thu Mar 01, 2012 7:11 pm

beau.styne wrote: The code that would not compile in 3.2.2 was written in .NET 3.5 framework. We received the following error "Default parameter specifiers are not permitted."
The .NET 3.5 Framework does not allow to specify default values for method parameters. You need to set the target framework for that project to 4.0 to successfully compile that code.
beau.styne wrote:hen using 3.1.3, VS2010 had already converted the Ranorex build, but, when using 3.2.2, anytime 3.2.2 touches the solution VS2010 needs to re-convert the project.
Setting the target framework to 4.0 will also cause the "ToolsVersion" in the project file to be set to "4.0", resulting in VS 2010 not converting the project file again.

Regards,
Alex
Ranorex Team
.
Image

beau.styne
Posts: 3
Joined: Thu Mar 01, 2012 5:32 pm

Re: Ranorex 3.2.2 Compile Error

Post by beau.styne » Tue Mar 06, 2012 10:38 pm

Just as clarification:
The specs of the development computers we are using are as follows:
Windows 7 (64-bit)
.NET 4.0 Client Profile
.NET 4.0 Extended
.NET 4.0 Multi-Targeting Pack
Visual Studio 2010
Using Ranorex 3.2.1 due to compiling issues in 3.2.2
In Ranorex, our build configurations and platforms are all set to AnyCPU with .NET 3.5 as our target framework

Also, the testing computers we use for our Ranorex automation runs are a combination of 32 and 64-bit OS's. The program we are automating with Ranorex requires the use of .NET 3.5 framework.

The compiler in Ranorex 3.2.1 and previous versions have no problem compiling and running the debug tasks. However, the default parameters specifiers are not permitted (mentioned in my previous post) in Ranorex 3.2.2 even though Visual Studio 2010 and earlier builds of Ranorex compiled without complaints.

In response to your reply:
Support Team wrote:The .NET 3.5 Framework does not allow to specify default values for method parameters. You need to set the target framework for that project to 4.0 to successfully compile that code.
-The .NET 3.5 framework did allow those default values for method parameters in the versions prior to Ranorex 3.2.2
Support Team wrote:Setting the target framework to 4.0 will also cause the "ToolsVersion" in the project file to be set to "4.0", resulting in VS 2010 not converting the project file again.
-Again, the previous versions of Ranorex had no issues integrating with VS2010.

Our Question:
What changed from 3.2.1 build to 3.2.2 build in way of compiling?

- The reason for this question arises from the fact that Visual Studio 2008 throws the same exceptions as 3.2.2 whereas VS2010 and previous versions of Ranorex do not. In the research we conducted, we found that the default parameters specifications were released with C# 4.0, not with .NET 4.0. And Visual Studio 2010 is the implementation of C# 4.0, whereas previous versions of Visual Studio are not.

http://msdn.microsoft.com/en-us/library/dd264739.aspx (particularly the Community Content section at the bottom and the "Request for clarification" post within the section)

Thank you for your time,
Beau Styne

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Ranorex 3.2.2 Compile Error

Post by Support Team » Thu Mar 08, 2012 4:49 pm

beau.styne wrote:Our Question:
What changed from 3.2.1 build to 3.2.2 build in way of compiling?
In Ranorex Version 3.2.2 we tried to fix some issues related to various 'ToolsVersion - Target Framework' configurations.

Unfortunately we added a fix which auto-sets the 'Tools Version' to 3.5 when the 'Target Framework' is set to 3.5 in a Visual Studio 2010 project. Evidently MSBuild can not recognize the CSharp 4.0 language specification because of the corresponding MSBuild Tool Set.

In the effort to provide the best possible Multi-Target Framework support we attempt to add an adequate solution to our next Ranorex release (i.e. most likely removing the auto-set code for 'Tools Version').

Best regards,
Christian
Ranorex Team
.
Image

beau.styne
Posts: 3
Joined: Thu Mar 01, 2012 5:32 pm

Re: Ranorex 3.2.2 Compile Error

Post by beau.styne » Tue Apr 03, 2012 4:13 pm

I just want to clarify if this issue was corrected in 3.2.3 or will be fixed in a later release? I was not 100% sure the release notes of 3.2.3 addressed what we had spoken of. If it had, I apologize for the mistake.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Ranorex 3.2.2 Compile Error

Post by Support Team » Wed Apr 04, 2012 10:29 am

Hi,

the bug has been fixed with Ranorex 3.2.3 and everything should work as expected.

Regards,
Tobias
Ranorex Team
.
Image