RSS

Tag Archives: Visual Studio

Microsoft Products Retirement

Earlier, I was not sure if I can share the information outside, but got a confirmation today that I can.

Microsoft shared the following information with us in order to be better prepared for the upcoming year.
These are the Microsoft products that are going to retire this year and be End Of Life, meaning – End of support.

Product End Of Life Date
SQL Server 2000 4/9/2013
Commerce Server 2002 7/9/2013
BizTalk Server 2004 7/8/2014
Project Server 2003 4/8/2014
Live Communication Server 2003 1/14/2014
Office 2003 4/8/2014
Windows XP 4/8/2014
.NET Framework 1.1 10/8/2013
Visual Studio .NET 2003 10/8/2013

It is suggested by Microsoft that we migrate to newer version if we are using any one of these products.
So please have a look at what version you are working on currently and take necessary action if needed.

Advertisements
 
Leave a comment

Posted by on March 5, 2013 in Microsoft

 

Tags: , , , ,

“Cannot evaluate expression because the code of the current method is optimized”

Problem description:
This is one the common error faced by a lot of Visual Studio users. Typically, they get the below error message during debugging:

“Cannot evaluate expression because the code of the current method is optimized.”

Assessment:
In .NET, “Function Evaluation (funceval)” is the ability of CLR to inject some arbitrary call while the debuggee is stopped somewhere. Funceval takes charge of the debugger’s chosen thread to execute requested method. Once funceval finishes, it fires a debug event. Technically, CLR have defined ways for debugger to issue a funceval.

CLR allows to initiate funceval only on those threads that are at GC safe point (i.e. when the  thread will not block GC) and Funceval Safe (FESafe) point (i.e. where CLR can actually do the hijack for the funceval.) together. Thus, possible scenarios for CLR, a thread must be:

1. stopped in managed code  (and at a GC safe point): This implies that we cannot do a funceval in native code. Since, native code is outside the CLR’s control, it is unable to setup the funceval.

2. stopped at a 1st chance or unhandled managed exception (and at a GC safe point): i.e at time of exception, to inspect as much as possible to determine why that exception occurred. (e.g: debugger may try to evaluate and see the Message property on raised exception.)

Overall, common ways to stop in managed code include stopping at a breakpoint, step, Debugger.Break call, intercepting an exception, or at a thread start. This helps in evaluating the method and expressions.

Refer: MSDN Blog: Rules of Funceval

Possible resolutions:
Based on the assessment, if thread is not at a FESafe and GCSafe points, CLR will not be able to hijack the thread to initiate funceval. Generally, following helps to make sure funceval initiates when expected:

Step #1:

Make sure that you are not trying to debug a “Release” build. Release is fully optimized and thus will lead to the error in discussion. By using the Standard toolbar or the Configuration Manager, you can switch between Debug & Release.

For more details about it: How to: Set Debug and Release Configurations

Step #2:

If you still get the error, Debug option might be set for optimization. Verify & Uncheck the “Optimize code” property under Project “Properties”:

  • Right click the Project
  • Select option “Properties”
  • Go to “Build” tab
  • Uncheck the checkbox “Optimize code”

Step #3:

If you still get the error, Debug Info mode might be incorrect. Verify & set it to “full” under “Advanced Build Settings”:

  • Right click the Project
  • Select option “Properties”
  • Go to “Build” tab
  • Click “Advanced” button
  • Set “Debug Info” as “full”

Step #4:

If you still face the issue, try the following:

  • Do a “Clean” & then a “Rebuild” of your solution file
  • While debugging:
    1. Go to modules window (VS Menu -> Debug -> Windows -> Modules)
    2. Find your assembly in the list of loaded modules.
    3. Check the Path listed against the loaded assembly is what you expect it to be
    4. Check the modified Timestamp of the file to confirm that the assembly was actually rebuilt
    5. Check whether or not the loaded module is optimised or not
  • Remote chance could be that your call stack is getting optimized because your method signature is too large (more than 256 argument bytes). Read more about it at this MSDN blog

Conclusion:
It’s not an error but an information based on certain settings and as designed based on how .NET runtime works.

 
1 Comment

Posted by on January 26, 2013 in ASP.NET, Visual Studio

 

Tags: , , , ,