We Keep Coding

ICE: trying to add a local var with the same name, but different types. during [_RegisterClipboardFormat]

I have a PoC to use some existing Java-codebase in some UWP-app using the most current Visual Studio Community 19 version 16.3.2 and the latest released IKVM 8.1.7195.0. The app builds and runs fine in Debug-mode, but fails to build already in Release-mode with the following error:
MCG0004:InternalAssert Assert Failed: ICE: trying to add a local var
with the same name, but different types. during
[_RegisterClipboardFormat] Ams.Oms.Poc
RegisterClipboardFormat is part of IKVM:
#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
return _RegisterClipboardFormat(format);
}
https://github.com/ikvm-revived/ikvm/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
What I'm wondering is which local variable the error message is referring to? Might be something added implicitly or might have to do with String in Java vs. string in C#? OTOH that file is clearly named .java.
Didn't find much about the error message in general, only the following two links seems to be more interesting:
Variables having same name but different type
Why doesn't C# allow me to use the same variable name in different scopes?
So I'm currently even unsure where the message comes from, Visual Studio/C# directly or IKVM during running code during building Release-mode. I strongly suspect the error is coming from Visual Studio/C#, though.
Searching for the function itself doesn't reveal much of help as well:
Sorry, AWT is not a supported part of IKVM.
https://sourceforge.net/p/ikvm/bugs/225/
Others seemed to have the same problem, because CN1 simply disabled that code entirely in their fork of IKVM:
//#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
//private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
throw new Error("Not implemented");
//return _RegisterClipboardFormat(format);
}
https://github.com/ams-ts-ikvm/cn1-ikvm-uwp/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
Any ideas? Thanks!

There seems to be a workaround by not changing any code at all: The settings of the Release-build contain a checkbox if to use the .NET native toolbox for the build, which is enabled by default. By disabling that the build succeeds without any code change and is as fast as the Debug-build again. Before changing that, the Release-build took a lot longer as well.
Don't know what that means regarding actually calling native code, if that fails or not, because my app doesn't use those. I guess it would fail, depending on if it works in Debug or not. Additionally, I'm not sure if the Windows store accepts such a modified Release-build, but as UWP-apps aren't forced to use native code at all, I guess there's a good chance things are going to work.

how to solve RDotNet REngine nullreference exception

I am trying to use the REngine.GetInstance() function but I keep getting a null reference exception.
I have tried using another function in REngine just in case the getInstance method was at fault, like REngine.SetEnvironmentVariables(), yet they all return the null reference exception.
I have tried reinstalling the package. I have tried checking the installation path but I couldn't find how the rdotnetlibrary accesses it. I am not even sure the path is related to the problem.
Please help.

Make sure your startupparameters are set up correctly. Since you do not provide us enough information; this is a correct way to get r.net's REngine running:
//...
StartupParameter rinit = new StartupParameter();
rinit.Quiet = true;
rinit.RHome = "C:/Program Files/R/R-3.4.3";
rinit.Interactive = true;
REngine.SetEnvironmentVariables();
rMain = REngine.GetInstance(null, true, rinit);
//...
Make sure you setup RHome to the correct installed R path.
EDIT (thanks to #David M.): In usual cases you only need to pass StartupParameter to GetInstance() if you don't want to have default initialization settings. However, according to the source code comments for the first parameter:
The file name of the library to load, e.g. "R.dll" for Windows. You usually do not need need to provide this optional parameter
In rare cases you need to provide the path of R.dll:
//...
rMain = REngine.GetInstance("C:/Program Files/R/R-3.4.3/bin/x64/R.dll", true, rinit);
//...

I've had the same issue using version 3.5.0
a call to "REngine.GetInstance" would result in 'Object reference not set to an instance of an object'
I downgraded to 3.4.0 and I'm not getting that error anymore.

When we upgraded R from 3.4 to 3.5, we got that exact error. We downgraded back to 3.4 and moved on.

As other answers have pointed out, this appears to be an issue relating to R 3.5 and above. I also managed to work around this by downloading R 3.4.4 and having both versions run concurrently, using Shique's solution.
For those unable to downgrade their R, it looks like jmp75 has been working on a fix, and there is a WIP branch available at https://github.com/StatTag/rdotnet/tree/r_3_5_0

How do I get CallerFilePath and CallerLineNumber without using the CallerInfo attributes?

For my log4net solution, I have an API wrapper that uses the CallerInfo attributes, e.g.
public void Write(string message,
[CallerMemberName] string memberName = "",
[CallerFilePath] string filePath = "",
[CallerLineNumber] int lineNumber = 0)
However, I am also using Unity Interception so that I can perform trace logging of the before/after responses, e.g. using ICallHandler like below in the Invoke method.
public class TraceCallHandler : ICallHandler
{
...
public IMethodReturn Invoke(IMethodInvocation input,
GetNextHandlerDelegate getNext)
{
//---- Trace method inputs
this.LogInfoBeforeInvoke(input);
//---- invoking the target method
InvokeHandlerDelegate next = getNext();
IMethodReturn methodReturn = next(input, getNext);
//---- invoking the target method
this.LogInfoAfterInvoke(methodReturn.ReturnValue);
}
}
Note: The above code is in no way complete/correct... but just wanted to show you what I was doing for Unity Interception.
My question / challenge is this:
when I eventually call log.Write(...), I want the target's caller info, not my TraceCallHandler info.
e.g. for method name, I can do this:
string methodName = input.MethodBase.Name;
How do I get the Caller's File Path and Caller's Line Number? Is it even possible to do via reflection?
Thanks!

Yes, you can get these using reflection:
var sf = new System.Diagnostics.StackTrace(1).GetFrame(0);
Console.WriteLine(" File: {0}", sf.GetFileName());
Console.WriteLine(" Line Number: {0}", sf.GetFileLineNumber());
// Note that the column number defaults to zero
// when not initialized.
Console.WriteLine(" Column Number: {0}", sf.GetFileColumnNumber());
However as it says clearly in the documentation:
StackFrame information will be most informative with Debug build
configurations. By default, Debug builds include debug symbols, while
Release builds do not. The debug symbols contain most of the file,
method name, line number, and column information used in constructing
StackFrame objects.
So if all you want this for is debugging, then enable it in debug builds and log away. In Release builds though it will be at best unhelpful and at worst downright misleading as apart from the symbol considerations above the compiler will aggressively inline methods and reorder things and generally mess with your stuff.

I just ran across this issue and thought I would share what I learned. First, when you include [CallerFilePath] in a method argument a side effect is that the full path of the file, including any user identifiable data, will be included in your .exe. I created a simple program with one method. I created an exe. I then added a [CallerFilePath] attribute to the test function. When I compared the results of strings.exe (from sysinternals), the one with the attribute differed in that it included the full path of my source file.
c:\users\<my name>\documents\visual studio 2015\Projects\TestCallerAttribute\TestCallerAttribute\Program.cs
The answer above by stuartd is correct in that you will not be able to get the data you want from the stack trace in a release build.
There is a solution to getting strong data however: Event Tracing for Windows. From msdn: "Event Tracing for Windows (ETW) is an efficient kernel-level tracing facility that lets you log kernel or application-defined events to a log file. You can consume the events in real time or from a log file and use them to debug an application or to determine where performance issues are occurring in the application."
This is not a quick solution. There is work in setting up the events and the listeners to get the provenance you need. The long term payoff is strong.

"The invocation of the constructor on type 'TestWPF.MainWindow' that matches the specified binding constraints threw an exception."- how to fix this?

I'm working with WPF. When I'm trying to declare SQLiteConnection in the code, the problem arises-
The invocation of the constructor on type 'TestWPF.MainWindow' that matches the specified binding constraints threw an exception.
InnerException: Make sure that the file is a valid .NET Framework assembly.
can anyone tell me, how to fix it?

If you click on View Detail... from the exception window you can look at the InnerException. Expand that node and you will see exactly what went wrong.

In my specific case, I was getting this because I had a few of my referencing assemblies mismatched between x64 and x86. Apparently I was binding to something that needed to be loaded by the runtime.
I mention this here as a reminder to check your build configurations if you've looked everywhere else!

I fixed the problem by adding the below content in app.config,
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true" /> </configuration>
I found this via a community addition by user FCAA below the article "
Troubleshooting Exceptions: System.IO.FileLoadException" on MSDN.

I got the same error and, after wasting about 2 hours with it, found that it is my SQL Server service that's not running. Not sure if this can ever help someone, but it did solve my problem to just start the service.

The mentioned exeption is quite generic and you can receive it, for instance, when code fails in the constructor. I had a case of an IO exception that showed up with a similar text. Stepping into the code may provide hints to fix this that may not be obvious otherwise.

I got it in when I specified the FrameworkPropertyMetadata of a DependencyProperty with a default value
the defaultValue was
new AdressRecord { Name = "<new>", Adress = "?" }
i replaced with
default(AddressRecord)
and vs2015 ate it
public static readonly DependencyProperty AdressRecordsProperty =
DependencyProperty.Register("AdressRecords",
typeof(ObservableCollection<AdressRecord>),
typeof(PageViewModel),
new FrameworkPropertyMetadata(
default(AdressRecord),//This noes not work: new AdressRecord { Name = "<new>", Adress = "?" },
OnAdressRecordsChanged));

I ran into this issue and it was caused because my startup application was built as any CPU but I was referencing a project that was built as x64. Setting the startup to build x64 resolved the issue.

In VS2015 I was able to see the specific code causing this problem once I turned on 'Enable Just My Code' in the Debugging Options under Tools -> Options.

I had this error in another part of code which has to do with my application resources.
This was fixed after explicitly setting the ResourcePath folder in my App.config file

I had the same problem. i could make it work by renaming the name of App1.config to App.config. I tried all other methods but the solution for me was to change the default name (for me it was App1.config) of the config file to App.config. I shared this because someone may get help by this small modification.

My problem was about the interface. I fixed it by deleting the Betternet folder that is located at C:\ProgramData.
Hidden Items/Folders must be shown in order to be able to view the folder.

With Visual Studio it will sometimes not show anything in the exception details or even have them, running the diagnostic tool however can easily pinpoint what is wrong.

Try Adding "Integreted Security = True" in Connection String.
It worked for me.

In my case it happened in a code-first WPF project. The cause was model changes after restoring a backup, and the error was not being handled appropriately. "The model backing the 'MyDataContext' context has changed since the database was created." Update-Database sorted it out.

I had to change the target .Net framework from 4.5.2 to 4.

my issue was regular System.IndexOutOfRangeException error in my own code,
but received this weird error because my code was called inside:
public MainWindow()
{
InitializeComponent();
// my code with error
}
same issue, if call it inside:
private void Window_Initialized(object sender, EventArgs e)
{
// my code with error
}
Fixed, if I call my code inside:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
// my code with error
}
Then i get correct error message for IndexOutOfRangeException in my code.

Code Contract : ccrewrite exited with code -1?

I'm new to code contracts. I downloaded the latest build of code contract project (1.4.40314.1) and started to implement it in my project. When i enabled 'Runtume Checking' through Code Contracts Tab in VS2010, i got this Error
Error 1 The command ""C:\Program Files (x86)\Microsoft\Contracts\Bin\ccrewrite" "#Application1ccrewrite.rsp"" exited with code -1.
everytime i build the project. Plz help.
Now it's a major problem for me.
Every project using code contracts is showing same error in VS2010 Errors window and 'Application1ccrewrite.rsp' not found in output window, but it is there.
I tried out everything. I installed both versions (Pro, Std) but the problem persist. Plz help !

I had this problem as well. In my case the problem was that ccrewrite cannot work with files in a network folder but requires the project to be on your local hard disk.

I had this problem. The Assembly name and Default namespace of the class library that causes the problem had the same name as an existing DLL in the destination folder. I had been refactoring my code and whilst the namespaces in the CS files had all be changed to namespace2 the default namespace in the properties file was still namespace1
When I corrected this the files all built successfully...

Sometimes you can get this when your solution path is too long, especially with many projects.
Try moving to c:\temp and building it, it might fix it (although of course, this might not be a solution if you need it in the folder it currently is).
This bug I noticed in earlier CC versions and may now be fixed.

I don't know if you had the same problem as me, but I also saw this error. In my case, I had a method with a switch statement, and depending on the branch taken, different requirements applied:
static ITransaction CreateTransaction(
String transType,
MyType1 parm1,
/* Other params unimportant to this example */
String parm5)
{
switch (transType) {
case Transaction.Type.SOME_TRANSFER:
Contract.Requires<ArgumentNullException>(parm1.Account != null, "Account cannot be null.");
Contract.Requires<ArgumentException>(!String.IsNullOrWhiteSpace(parm5), "parm5 cannot be null or empty.");
// Create instance
return someInst;
case Transaction.Type.SOME_OTHER_TRANSFER:
Contract.Requires<ArgumentException>(!String.IsNullOrWhiteSpace(parm1.Type), "Type cannot be null or empty.");
Contract.Requires<ArgumentException>(!String.IsNullOrWhiteSpace(parm1.Number), "Number cannot be null or empty.");
// Create instance
return someInst;
/* Other cases */
default:
throw new ApplicationException("Invalid or unknown transaction type provided.");
}
}
This was giving me the error you noted in the Errors List when I tried to build. In the output window, I was getting this:
EXEC : Reference Assembly Generator
warning : Something is wrong with
contract number 1 in the method
'TerraCognita.LoanExpress.Domain.Loan.CreateLoanTransaction'
AsmMeta failed with uncaught
exception: Operation is not valid due
to the current state of the object.
I pushed each branch into a method of its own, making Contract.Requires the first lines of code in each method, and I no longer had a compilation problem. It appears that Contract.Requires must be the first lines of code in a method - which makes sense, since they are intended to be used to define pre-conditions.
Hope this helps.

The solution is to put the pre and pos conditions in the first lines. The ccrewrite does not accept that pre and post conditions are below command lines.