We Keep Coding

R.NET works with x86 but not x64

I'm trying to build and run the Hello World sample at the tutorial page at R.NET. When I force the program to run in x86 mode, it seems to do OK. However, when I run in x64, it stops very early on with the message, "[program] exited with code-1073740791"
I've installed the latest version of R at The R Project and have ran the troubleshooting steps. The output I've gotten from the troubleshooting program is:
Is this process 64 bits? True
Info: caller provided rPath=null, rHome=null Info: R.NET looked for preset R_HOME env. var. Found null
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found sub-key InstallPath under RDotNet.NativeLibrary.WindowsRegistryKey
Info: InstallPath value of key RDotNet.NativeLibrary.WindowsRegistryKey: C:\Program Files\R\R-4.0.3
Info: R.NET looked for platform-specific way (e.g. win registry). Found C:\Program Files\R\R-4.0.3
Info: R.NET trying to find rPath based on rHome; Deduced C:\Program Files\R\R-4.0.3\bin\x64
C:...\bin\x64\Debug\net5.0\ConsoleNet5R.exe
(process 33500) exited with code -1073740791.
I have verified that there IS a file R.dll where it deduced it should be, "C:\Program Files\R\R-4.0.3\bin\x64". When I step through using my decompiler, it appears that it gets choked up at what is showing up for me as line 400 in REngine.cs, under the function "Initialize" at this.GetFunction<setup_Rmainloop>()(); It doesn't appear to throw an exception, it just stops. I'll be honest--I'm not sure what this line is supposed to be doing...
Any ideas what is going on? I can run in x86 mode if I have to, but I would like to use x64 if possible.

This issue has been reported for a while..
I experienced the same with R-4.0.3 to R-4.0.5.
There is not such issue for R-4.0.2 and former versions (4.0.1, 4.0.0, 3.6, 3.5)

I've done an analysis of this and tracked findings in one of the RDotNet GitHub issues where this was raised (https://github.com/rdotnet/rdotnet/issues/139#issuecomment-898699993).
This appears to be related to the Control Flow Guard security feature enabled in Windows 10. This doesn't happen in the R programs themselves because they are compiled using a different compiler (gcc via mingw) than Microsoft's. However, the CFG feature is enabled for .NET binaries and there is something (sorry, I don't know the actual underlying root cause) in a change within R 4.0.3 in setjmp/longjmp calls that is causing the crash (see: https://github.com/wch/r-source/blob/trunk/src/gnuwin32/fixed/h/psignal.h#L44-L51).
Although you would actually be disabling a security feature, I have had some luck for now in modifying my program after it is compiled (you can set this as a post-build event). You will need to run something like: link /EDIT /GUARD:NO <yourapp>.exe, which disables CFG.
Thanks to https://github.com/dotnet/runtime/issues/11899#issuecomment-502195325 for providing the instructions needed for this workaround, and https://www.trendmicro.com/en_us/research/16/j/control-flow-guard-improvements-windows-10-anniversary-update.html for providing the amazing analysis of CFG that led to an understanding of what was going on.

.NET executables do not work after overwritten with new versions

I faced very strange behaviour - after I overwrite .NET exectables with new versions from network drive it cannot start.
When try to start from Windows Explorer it shows me following error:
[Window Title]
C:\Programs\zzz\clients.net\zzzNet.exe
[Content]
C:\Programs\zzz\clients.net\zzzNet.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
I tried to execute following commands:
SxsTrace Trace -logfile:SxsTrace.etl
SxStrace Parse -logfile:SxSTrace.etl -outfile:SxSTrace.txt
And got following result:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = AMD64
CultureFallBacks = en-US;en;ru-RU;ru
ManifestPath = C:\Programs\zzz\clients.net\zzzNet.exe
AssemblyDirectory = C:\Programs\zzz\clients.net\
Application Config File = C:\Programs\zzz\clients.net\zzzNet.exe.Config
-----------------
INFO: Parsing Application Config File C:\Programs\zzz\clients.net\zzzNet.exe.Config.
INFO: Parsing Manifest File C:\Programs\zzz\clients.net\zzzNet.exe.
INFO: Manifest Definition Identity is (null).
ERROR: Line 0: XML Syntax error.
ERROR: Activation Context generation failed.
End Activation Context Generation.
It is quite simple .NET application (1 exe + 8 dll files). It was built for .NET 3.5 Client Profile.
I not defined any special "manifest" there. Just clicked "New Windows Forms Project" in Visual Studio and developed it.
Also app.config does not contain anything special - only primitive standard settings - appSettings and userSettings sections.
On PC where I developed it all is perfectly works. Problems only began when I copy these binaries to this particular VM and try to start.
Also please note - these executables were not installed in GAC or such, I just copied them into a folder on VM and started. And when it was 1st time all was working fine.
So, the problem pattern is following:
Copy .NET execuatbles to new VM (it is Win 7 x64), run it, all is working fine. Close it.
Build new version of .NET execuatbles on host PC, copy new .NET execuatbles to VM (with files overwriting).
Try to start - got mentioned problem.
After some shaman-style actions (like OS reboot, etc) it begin to work but why that happened at all?!
Why replacing .NET executables with new versions is causing SUCH HUGE PROBLEMS?!
Also the BIG QUESTION - is there any special procedure to replace .NET executables to keep them working? Because it is a new app development, I do not want lost so much time on every new executables installation. :-\
Could you please help? Because it looks completely weird!
Thank you in adance.
PS. I checked all VS projects - all they have PlatformTarget=AnyCPU. Also in run-time I can see ProcessType=MSIL (I show this info in AboutBox for application). So, there is no mix of x86/x64 binaries.

It seems that was related to mapped network drive behavior.
When I copied new files from network drive folder it copied wrong files - a strange random mess of new files and older ones (which were there before I updated them on VM host).
The scenario to make it working:
on VM: delete all files in a folder on network drive
on VM host: copy new files into a folder which is mapped as network drive on VM
on VM: copy files into target folder
on VM: run application - it works now
Weird thing. I remember I have seen something similar with Windows Explorer on Windows 2008 behaviour when copying updated win32 binaries.

Documentation needed on how to get FXCop running with Sonarqube 5.1

On the sonarqube website the new C# plugin documentation states 'native support for fxcop'
However there is no explanation how to get fxcop running. It does not work out of the box.
What i did so far and works:
installed Sonarqube 5.1
using msbuild.sonarqube.runner
The sonarqube C#,xml,js analysis al work like a charm.
What does not work is using fxcop rules.When i enable 1 rule i get the runner to give the following exception:
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLaunc
her.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53) Caused by: java.lang.IllegalArgumentException: The property "sonar.cs.fxcop.a
ssembly" must be set and the project must have been built to execute
FxCop ru les. This property can be automatically set by the Analysis
Bootstrapper for Visual Studio Projects plugin, see:
http://docs.codehaus.org/x/TAA1Dg.If you wish to skip the analysis of
not built projects, set the property "sonar.visu
alstudio.skipIfNotBuilt".
What i tried so far:
followed the provided docs.codehaus.org/x/TAA1Dg link but this is a dead link. It states "All Codehaus services have been terminated".
added sonar.cs.fxcop.assembly property to the sonarqube.analysis.xml but this does not change anything to the error.
added sonar.cs.fxcop.installdirectory property to the sonarqube.analysis.xml file. This changes the error messages to:
Caused by: java.lang.IllegalArgumentException: Cannot find the
assembly "C:\p
rojects\mercurial\ccvs.sonarqube\bin\sonar-runner\bin\"FxCopCmd.exe""
provided by the property "sonar.cs.fxcop.assembly".
But i'm unable to the the fxcop installation copied to this folder. I also failed to influence the path to be redirected to my fxcop installation which comes with vs2013(C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe)
Another thing is that the sonar-project.properties file next to the .sln file is not picked up by this new msbuild sonar runner thats why i edit the xml file.
In short a step-by-step on the guide how to get fxcop working together with sonarqube 5.1 and the msbuild sonarrunner on the site of sonarqube would be appreciated.

I thinks you should read
http://www.sonarqube.org/easy-analysis-of-visual-studio-solutions-with-the-sonarqube-scanner-for-msbuild/
and
http://docs.sonarqube.org/display/PLUG/C%23+Plugin .
Pay attention to the fact that you should run the commands from a "Developer Command Prompt for Visual Studio 2013 or higher" (http://docs.sonarqube.org/display/SONAR/Analyzing+with+SonarQube+Scanner+for+MSBuild).
Neither DOS Command Prompt nor Windows PowerShell work because they don't set the proper variables.
The FxCop native support doesn't mean that it comes with MSBuild SonarQube Runner, but you have to install Visual Studio >= 2013 (as I think you understood from your message).
Moreover, I found that not only sonar-project.properties has been deprecated, but you have to remove it to avoid strange behaviors.

Code Analysis Errors Only on Build Server

I'm trying to figure out why code analysis would run and detect errors on our build server, but I don't see the same errors when building locally. Here is one example of code that's failing (because of our STBi acronym):
string message = string.Format(CultureInfo.CurrentCulture,
"Unit STBi [{0}] blah... ",
unitStbiParameter.Stbi);
The build fails on our TFS build server with errors like this:
CA2204 : Microsoft.Naming :
Correct the spelling of the unrecognized token 'STBi' in the literal
'"Unit STBi ["'.
The problem is that I don't know why I'm not seeing these CA errors when I build the solution on my laptop. This is in the project's properties:
And the build definition has this:
Why would errors show from a build on the build machine but not my laptop? It's almost like the build server is using a different CA rule set. Is that possible?
Side note: I tried adding STBi to the CustomDictionary.xml (below), but that still didn't help. But that's a separate issue.
<!-- This is here because it's a workaround for a bug: http://connect.microsoft.com/VisualStudio/feedback/details/521030/ -->
<DiscreteExceptions>
<Term>STBi</Term>
</DiscreteExceptions>

You probably need to specify the CodeAnalysisCulture MSBuild property in your project(s) (see http://blogs.msdn.com/b/codeanalysis/archive/2007/08/12/new-for-visual-studio-2008-spelling-rules.aspx for an example). Without this set, spelling rules will use the Windows UI culture information for the account under which the analysis is running, which is presumably different for your account and the build account.

Are you building debug locally and release on the Build Server? If so, check that the CA settings are the same for debug and release, and that your dictionary is checked in and the same on the build server.
My team use CA enabled on debug builds and CA is disabled on the build server. The code analysis check-in policy ensures that CA has been run on all code in source control, so is there any point in slowing down your server builds with repeated code analysis passes?

Powershell, Service Bus For Windows Server Programmatically: Command found, module could not be loaded

From C# code I'm trying to retrieve all the namespaces from powershell... (Later more complex things, like creating namespaces)
PowerShell ps = PowerShell.Create();
ps.AddCommand("Import-Module").AddArgument("ServiceBus").Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Above code gives the following exception:
The 'Get-SBNamespace' command was found in the module 'ServiceBus',
but the module could not be loaded. For more information, run
'Import-Module ServiceBus'.
Does anyone know how to solve this error?
CURRENT STATUS: after some debugging I've found that no modules are loaded by default in the PowerShell object. Using the code:
InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new string[]{#"serviceBus"});
PowerShell ps = PowerShell.Create(iss);
doesn't work to load the service bus module. Also the code:
ps.AddCommand("Import-Module").AddParameter("-Name", "serviceBus").Invoke();
doesn't work to import the service bus module. Running Visual Studio in administrator mode also doesn't make a difference
Thanks in advance

You didn't say which version of Visual Studio you're using. If it's VS 2012, when you tried the x64 platform target did you make sure that "Prefer 32-bit" was not checked? Even if it was not checked try checking it, saving the project configuration, clearing it and saving again - this worked for me on another project.
UPDATE
It's been suggested elsewhere that there's a bug in VS2012 that shows "Prefer 32-bit" as greyed-out and unchecked when it's actually active. I'm running Update 2 and I don't see that. But it sounds like you might be. I suggest you edit the .csproj file directly.
Whilst "Platform Target" is set at "Any CPU", in Solution Explorer, right-click on the Project name (or, with go to the PROJECT menu) and select "Unload Project". Project files will close and Solution Explorer will display project name (unavailable) > The project file was unloaded:
Right-click on the Project name again and select "Edit project name.csproj". The file is XML and mostly comprises PropertyGroup and ItemGroup elements. In a console project, the first PropertyGroup usually contains a Platform element which should read AnyCPU if you followed my instructions above. The next two PropertyGroups are normally for Debug and Release configurations. If you've added another configuration, it will have its own PropertyGroup. In each of these, look for an element which reads:
<Prefer32Bit>true</Prefer32Bit>
What you should have is an element which reads:
<Prefer32Bit>false</Prefer32Bit>
Either change it or insert it (in each configuration ProjectGroup), save the file and close it. Back in Solution Explorer, right-click the project and select "Reload Project". Let me know if that solves it. You can confirm your PowerShell is now running 64-bit by get the result of
[System.IntPtr]::Size
e.g.
ps.AddScript("[System.IntPtr]::Size");
which will be 4 in an x86 process and 8 in an x64 process.
Which my project set up like this, I was able to load ServiceBus using:
ps.AddCommand("Import-Module").AddArgument("ServiceBus");
Hopefully, you will, too.

I don't have ServiceBus installed so I can't verify exactly what you've tried but
ps.AddCommand("Import-Module").AddArgument("ActiveDirectory").Invoke();
worked for me, so your original syntax looks good.
Just to test for failure, I tried:
ps.AddCommand("Import-Module").AddArgument("CheeseDirectory");
ps.Commands.Commands[0].MergeMyResults(PipelineResultTypes.Error, PipelineResultTypes.Output);
var importResult = ps.Invoke();
foreach (PSObject result in importResult)
{
Console.WriteLine(result);
}
and got
The specified module 'CheeseDirectory' was not loaded because no valid
module file was found in any module directory.
Have you tried similar?

Do you take care of your Assembly target in your C# program (x86 versus X64). The module may exist in one target, not in the other. PowerShell exists in both.

Seems you're trying to import some modules and execute the cmdlet or function inside the module, right?
So I think you could try the following code:
PowerShell ps = PowerShell.Create();
Assembly ass = Assembly.LoadFile(#"yourServiceBus.dll");
ps.AddCommand("Import-Module").AddParameter("Assembly", ass).Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Hope this could help.