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.

Call method from interface or abstract class within static void

I'm usually a javascript developer, but for my company I just started learning c# in order to use the CimatronE 13 API to develop custom command line PDM tools for this 3D modelling software.
As I'm making progress understanding the programming language, there's this frustrating situation where I want to use an API endpoint method but I can't manage to get it working.
The Cimatron documentation says the following:
IPdm::GetRelatedDocuments
Syntax: RelatedDocuments = GetRelatedDocuments ( DocumentPath );
This method allows you to get related files from compound types of files, for example Assembly or Drawing.
Input: (String) DocumentPath,
Path to file. For example \Documents\Location\Folder\Document. The file must be Assembly or Drawing.
Return: (Variant) RelatedDocuments,
Variant type array each element of which contain two dimensioned string type array of files related to selected one.
This looks pretty straight forward to me, so I tried calling it in multiple ways from within the static void Main() method, but I keep getting errors:
var RelatedDocuments = interop.CimBaseAPI.IPdm.GetRelatedDocuments("path");
CS0120: An object reference is required for the non-static field, method, or property 'IPdm.GetRelatedDocuments(string)'
interop.CimBaseAPI.IPdm pdm = new interop.CimBaseAPI.IPdm();
var RelatedDocuments = pdm.GetRelatedDocuments("path");
CS0144: Cannot create an instance of the abstract class or interface 'IPdm'
Any ideas? It's probably simple but I'm still a noob with c# :p
EDIT:
Cimatron documentation about the interface interop.CimBaseAPI.IPdm:
Properties:
Get
Query (String, DocumentEnumType, DocumentEnumUnit )
Variant
Methods:
A lot, including Variant GetRelatedDocuments ( String )

As how I see it now... interop.CimatronE.IPdm is an interface and in order to use it's methods, we first need access to the Cimatron application. Using the application object, we can use it's methods to get the desired interfaces such as IPdm and use their methods.
The following code gives no errors from the compiler but does when executing. This seems to be related to version 13 of CimatronE, since the application object works just fine using version 12. A lot has changed between these versions which I think is the reason the API is not functioning properly, outdated.
interop.CimAppAccess.AppAccess AppAcc = new interop.CimAppAccess.AppAccess();
interop.CimatronE.IApplication CimApp = /*(interop.CimatronE.IApplication)*/AppAcc.GetApplication();
interop.CimatronE.IPdm pdm = CimApp.GetPdm();
var RelatedDocuments = pdm.GetRelatedDocuments("path");
Console.WriteLine(RelatedDocuments);
Please correct me if I'm wrong! (since I just started and still learning c#)

I ran into this same issue with Cimatron 14.
I needed to make some changes in Visual Studio for things run properly with Cimatron.
Run Visual Studio in administrator mode
Set your Debug & Release Solution Platform to 'x64'
It was also recommended to point the build path for release & debug to the same folder as the Cimatron references. In my case 'C:\Program Files\3D Systems\Cimatron\14.0\Program'. However my code appears to run fine without this.
I created the Cimatron Application with this code (VB.Net):
Dim gAppAccess As New CIMAPPACCESSLib.AppAccess 'Define an AppAccess object to get running active application
Dim gApp As CIMAPPACCESSLib.Application 'Define an Application object
gApp = gAppAccess.GetApplication 'Getting running active application
If gApp Is Nothing Then
gApp = New CIMAPPACCESSLib.Application 'Creating a new instance of a Cimatron application
End If
References: Interop.CIMAPPACCESSLib.dll & interop.CimServicesAPI.dll
It is my understanding that Cimatron 15 may also requires some manifest changes.
There is some help information in the Cimatron program under Cimatrom Modules > Cimaton SDK that may be mildly helpful.

How do I make CloudConfigurationManager.GetSetting less verbose?

I'm currently using CloudConfigurationManager.GetSetting("setting") to get settings for my application, but it's writing logs of everything it's checking to the console (in both Debug and Release):
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Is there any way to prevent it from doing this, or an alternative version that's less verbose?
Mostly I just like my unit test output to be nice and clean, but I'm also a little concerned that it's printing out things like connection strings (and hence passwords) in plain text on the production server.

CloudConfigurationManager.GetSetting now has a method overload with a parameter called outputResultsToTrace.
If you pass false to this method, then it'll disable the Trace.WriteLine used elsewhere to "spam" the Trace log.
So
var mySetting = CloudConfigurationManager.GetSetting("MySetting");
becomes
var mySetting = CloudConfigurationManager.GetSetting("MySetting", false);
I found this by looking directly at the source code on GitHub: https://github.com/Azure/azure-sdk-for-net/blob/52fc67253a176bea01c37c164f71c7eba8eaedba/src/Common/Configuration/CloudConfigurationManager.cs#L35
It's probably worth mentioning that this overload is not documented: https://msdn.microsoft.com/en-us/library/azure/mt634648.aspx
So I'm not sure if it's an official and supported part of the API, or if it's something that might change or go away in the future.
This change was made at the end of 2015: https://github.com/Azure/azure-sdk-for-net/commit/e14398136d7d3b6d5e4675f1e8ccbdd37a8c6b01

Not really. If you look at the code of the underlying GetValue method you'll see this:
private static string GetValue(string providerName, string settingName, Func<string, string> getValue)
{
string str1 = getValue(settingName);
string str2;
if (str1 != null)
str2 = string.Format((IFormatProvider) CultureInfo.InvariantCulture, "PASS ({0})", new object[1]
{
(object) str1
});
else
str2 = "FAIL";
Trace.WriteLine(string.Format((IFormatProvider) CultureInfo.InvariantCulture, "Getting \"{0}\" from {1}: {2}.", (object) settingName, (object) providerName, (object) str2));
return str1;
}
The Trace.WriteLine is always called without taking into account Debug or Release. Now you can simply remove the Default listener which should suppress all messages:
<system.diagnostics>
<trace>
<listeners>
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
Now if you look at the CloudConfigurationManager it doesn't do that much. If this is a problem for you you can cook up something yourself, starting with this:
if (RoleEnvironment.IsAvailable)
return RoleEnvironment.GetConfigurationSettingValue(setting);
else
return ConfigurationManager.AppSettings[setting];
Note: The CloudConfigurationManager does a lot more than this, like loading the assembly without assembly reference.

Alternative option, if you're calling CloudConfigurationManager.GetSetting() in one part (ie, a wrapper/helper class):
var oldListeners = Trace.Listeners.Cast<TraceListener>().ToArray();
Trace.Listeners.Clear();
var stringValue = CloudConfigurationManager.GetSetting(key);
Trace.Listeners.AddRange(oldListeners);
First, we remove all listeners on Trace. Then we grab the setting, and re-add the listeners. Of course, this potentially could cause problems with threaded applications

I just installed the nuget package Microsoft.WindowsAzure.ConfigurationManager version 3.1.0, and I can confirm that the issue has been fixed in this version. Taking a look at the github issue referenced in the question's comments, we can see, in the changelog, the fetched value is no longer written to the trace output. In particular, the trace message has been changed from:
message = string.Format(CultureInfo.InvariantCulture, "PASS ({0})", value);
to:
message = "PASS";
This still makes the configuration manager quite verbose though.

We just ran into this ourselves...so very frustrating.
We can't remove the default listener because we are logging our own stuff on it.
There is an easy workaround though. Just use the good old fashioned ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"] and you will get the info you need without the annoying logging.
Hope that helps,
David

I had quite similar problems. I updated from Azure SDK 2.0 to 2.2 - during this process I used the NuGet Manager to update the Microsoft.WindowsAzure.Storage to the latest. The PackageManager automatically took Microsoft.WindowsAzure.Configuration to 1.8.0.0. I was not able to get this running (it was for .Net 2.0!?). After I manually set all References to
Microsoft.WindowsAzure.Storage 2.1.0.0
Microsoft.WindowsAzure.Configuration 2.0.0.0
everything worked.
I think this is because of the way CloudConfigurationManager.GetSetting loads the assembly and calls the funktions (via reflection).

Fixed in version 3.0.0. Please update Microsoft Azure Configuration Manager nuget package.

There are two separate issues here:
Setting values are logged in plain text (a security concern)
Messages are logged every time a setting is retrieved (a verbosity concern)
As others have noted, #1 has been fixed in a more recent version of the plugin.
Based on my experience (and some of the other responses here), #2 is still a huge annoyance.
Looking at WADLogsTable in Visual Studio's Queue Editor, note that the message level is 5 (i.e. verbose, according to this list of ETW levels).
Going off of the diagnostic config file schema, my approach to solving issue #2 was to limit the minimum severity level (e.g. warning, informational, verbose) of generic tracing to "information" (or more severe) and just ensure my own logging did not use the "verbose" level.
Here is the change I made in diagnostics.wadcfgx:
Original:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose" />
Fixed:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Information" />

How to add a property to a document type in Umbraco from code?

Could anyone give me an example of how to programatically add a property to an existing document type in Umbraco CMS? This is what I tried:
var dt = DocumentType.GetByAlias("TestDocType");
dt.AddPropertyType(new DataTypeDefinition(-49),"testprop", "test prop");
But it throws an exception:
Method not found: 'Void umbraco.cms.businesslogic.ContentType.AddPropertyType(umbraco.cms.businesslogic.datatype.DataTypeDefinition, System.String, System.String)'.
Any ideas?

I managed to fix it. The website was recently upgraded from Umbraco 4.5 to Umbraco 4.7.1, so the dll's had to be replaced with the more recent ones. In the older version of Umbraco the method's return type was public void AddPropertyType whereas the new one public PropertyType AddPropertyType. Apparently during the upgrade the new cms.dll wasn't copied over, so I copied it from a clean Umbraco 4.7.1 solution, changed the code to receive the return type and it helped.
Required namespaces:
using umbraco.cms.businesslogic.datatype;
using umbraco.cms.businesslogic.web;
So the final code(assuming correct assemblies are referenced):
var dt = DocumentType.GetByAlias("TestDocType");
var pType = dt.AddPropertyType(new DataTypeDefinition(-49),"testprop", "test prop");

That code looks fine to me, it should work.
Make sure your first line is actually returning a documentype, not null.
Also, do you have the proper 'usings' in place, you'll need at least some of these?
using umbraco.cms.businesslogic.web;
using umbraco.NodeFactory;
using umbraco.cms.businesslogic.member;
using umbraco.cms.businesslogic.datatype;

"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.