Develop Reference

Cannot use r.net within a wcf service

I am trying to set up an R.net WCF service as a server to run R commands on.
I have set up a test WinForms application where everything works.
This is how I use it:
void init()
{
SetupPath()
engine = REngine.GetInstanceFromID("test");
if (engine == null) engine = REngine.CreateInstance("test");
engine.Initialize();
}
...
results.Add(engine.Evaluate(command).AsCharacter().ToArray());
I created an equivalent WCF service which should work exactly the same;
REngine.CreateInstance() returns a valid REngine object,
engine.Initialize() silently crashes my service. Try-Catch section is ignored so I cannot see what exactly is happening.
What is the correct way to use R.net within a WCF service?
What could be the reason of different behaviours?
Where can I see detailed logs of the crash?
Service calls which don't use R.net complete successfully.
Both winforms test application and WCF service are 64 bit (i need them to be). (I did not manage to set up a 64-bit IIS express application, so am using IIS instead).

I did not manage to find the reason of the problem, however, switching to R.NET.Community package did the trick.

Puzzling differences in behavior between console and web apps

I have a piece of code in a Web API app:
private Stream ConvertWorkBookToStream(WorkBook workBook)
{
var tempFileName = Path.GetTempFileName();
// The following line throws a NullReferenceException
workBook.write(tempFileName);
// Remainder elided for brevity
}
Neither workBook nor tempFileName are null.
On a whim, I changed the app pool to run under a domain administrator account, to eliminate any permissions issues (since I've observed some general wonkiness on my machine of late) and re-ran it. The same exception was thrown.
Then I created a console application and copied the method, verbatim, into the app and ran it. No exception was thrown.
Now, it bears noting that just yesterday, I ran into a similar puzzling behavior regarding File.Exists.
Consider the following call:
var exists = File.Exists(#"\\myshare\\myexistingfile.ext");
Assuming that the path refers to a file that actually exists:
Under a web app, exists returns false on my machine.
The same operation, in a console application, returns true.
My coworkers are experiencing the opposite behaviors.
Can anyone explain this? I'm rather at my wits' end.

Check to see if the return from Path.GetTempFileName is different from the console app and the web app. Windows could be playing tricks with you. I had similar issues attempting to write log files. I just gave up and put them int the same directory as my web service.

In your IIS Authentication settings, are you only having Anonymous Authentication enabled? If I remember correctly Anonymous Authentication impersonates the IUSR account with restricted privileges.

WCF Data Service 5.6 quick start

I have been trying to get a WCF Data Service server working for a few days now.
I finally backed off today and just tried to do exactly what the quick-start shows.. nothing else.. and in completely fresh project. Surely that would work.
But it didn't.. it failed the same way as my other tests.
I am just following along with this example. Using Visual Studio 2013 for Web express and the hosting is using IIS Express.
I have installed the WCF Tools version 5.6 such that Visual Studio has the WFC Data Service 5.6 template.
The gist of it is
create an ASP.Net Application Select MVC type, adding no folders for anything other than MVC and no unit tests, individual account authenticaion.
Add an ADO.Net Entity Data Model for the NorthWind database, called NorthwindEntities in web.config, importing all tables.
Add WCF Data Service 5.6 item, call it NorthWind.svc.
Change the NorthWind.svc.cs backing code to the following.
using System;
using System.Collections.Generic;
using System.Data.Services;
using System.Data.Services.Common;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;
namespace StackOverflowApp
{
public class NorthWindService : DataService<NorthwindEntities>
{
// This method is called only once to initialize service-wide policies.
public static void InitializeService(DataServiceConfiguration config)
{
config.UseVerboseErrors = true;
config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead | EntitySetRights.WriteMerge | EntitySetRights.WriteReplace );
config.SetEntitySetAccessRule("Order_Details", EntitySetRights.AllRead| EntitySetRights.AllWrite);
config.SetEntitySetAccessRule("Customers", EntitySetRights.AllRead);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
}
}
}
Now it is ready to build and run.. it should work.. yes?
I run it, and navigate to the service.. I am greeted with the following complaint.
<div id="content">
<p class="heading1">Request Error</p>
<p>The server encountered an error processing the request. See server logs for more details.</p>
</div>
How am I to debug that?
This is not the typical response when navigating to a page which generates an error in the application or to a page that does not exist. I get the feeling that the data.service system is generating this response.. that it actually started to process the request.. but failed for some obtuse reason.
I followed the instructions to a tee I thought, but apparently I missed something.
I've been through the process step by step several times now to try to find what I might have skipped to no avail.
Update:
Aha.. under another similar question, they recommended adding verbose messages using config.UserVerboseErrors = true. This didn't make any difference to me.. but the alternative method of using attributes sure did! Decorating the class with [ServiceBehavior(IncludeExceptionDetailInFaults = true)], now yields this more descriptive error.
The server encountered an error processing the request. The exception
message is 'Expression of type
'System.Data.Entity.Core.Objects.ObjectContext' cannot be used for
return type 'System.Data.Objects.ObjectContext''. See server logs for
more details. The exception stack trace is: blahblah

It sounds like you're using Entity Framework 6 which hasn't been out for all that long. You need to perform some additional steps to get WCF Data Services 5.6 and EF 6 to behave together nicely.
You need to add the additional WCF Data Services Entity Framework Provider Nuget package and then instead of inheriting your service from DataService<T>, you inherit from EntityFrameworkDataService<T>.
Full steps are on the data services blog here: http://blogs.msdn.com/b/astoriateam/archive/2013/10/02/using-wcf-data-services-5-6-0-with-entity-framework-6.aspx

Yes Thanks. Your answer is correct Chris. I was able to find the problem at last after I enabled the decorated version of verbose messaging, and got that extra detail regarding linking to objects being the problem.
So I found the problem and fixed it, or at least I can make it work using the quick-start guide now. Working with my own database is a little squirley still.. returns an empty set when I know I have items in the database.. but at least I now have working exhibit-A to compare against to find the issue. (Aha! found the problem there also, I had forgotten to add the entitie connection to web.config for my non-northwind database -- so its all workin' now!)
Anyway, the first decent clue was following the error message (that wasn't shown until after I enabled verbose messaging with the class attribute), found this note about the problem actually being with WCF's interface with EntityFramework 6. (had I not upgraded to version 6 I likely would not have had the problem)
https://entityframework.codeplex.com/workitem/896
Then, I searched for issues with WCF 5.6 and EntityFramework6. and whalla.. there is an alpha version of WCF which addresses the issue.
Note that if you follow the instructions here verbatim, there is still a problem (or was for me). Get alpha2 instead of alpha1 as it fixes a linking error. i.e.
Install-Package Microsoft.OData.EntityFrameworkProvider -Version 1.0.0-alpha2 -Pre
http://blogs.msdn.com/b/astoriateam/archive/2013/10/02/using-wcf-data-services-5-6-0-with-entity-framework-6.aspx

To install alpha2 today 6/7/2014 "Install-Package Microsoft.OData.EntityFrameworkProvider -Pre". Also the Microsoft.Data.Services version must be 5.6.0.0.

O365 via PowerShell in ASP.NET MVC 3: MicrosoftOnlineException was thrown

I have an ASP.NET MVC 3 application which uses PowerShell to connect to Office 365 to retrieve some details about user licenses.
The code itself works in many cases:
The project in my local IIS works
A piece of code in LINQPad using the library works on my machine
A piece of code in LINQPad using the library works on the target server
And where it doesn't work is of course the only place it really should work: The IIS on the target server.
I always get an Exception when calling the Connect-MsolService cmdlet. The problem is that the Exception doesn't tell me anything.
The Exception type is
Microsoft.Online.Administration.Automation.MicrosoftOnlineException
and the message is
Exception of type 'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was thrown
which is pretty useless.
The Office 365 user account I use in my code is always the same. The user account used to start the IIS is always the same, too (Local System).
I wrapped the PowerShell code execution in a class named PowerShellInvoker. Its code can be found here.
And here is the code that connects to Office 365:
var cred = new PSCredential(upn, password);
_psi = new PowerShellInvoker("MSOnline");
_psi.ExecuteCommand("Connect-MsolService", new { Credential = cred });
There is no Exception actually thrown, the error is found in the Error property of the pipeline. (See lines 50ff. of the PowerShellInvoker class.)
The problem is that I don't know what could be wrong, especially because the same code works when I use LINQPad. The search results by Google couldn't help me either.
The server runs on Windows Server 2008 R2 Datacenter SP1 with IIS 7.5.

I found the solution!
I don't know the reason, but on the target server, the app pool's advanced settings for my app had set Load User Profile to False. I changed it back to True (which should be default) and voilà, it works!
Edit: The Load User Profile setting was apparently automatically set to False by default because the IIS 6.0 Manager was installed and False was the default behavior until IIS 6.0.

How to use ServerManager to read IIS sites, not IIS express, from class library OR how do elevated processes handle class libraries?

I have some utility methods that use Microsoft.Web.Administration.ServerManager that I've been having some issues with. Use the following dead simple code for illustration purposes.
using(var mgr = new ServerManager())
{
foreach(var site in mgr.Sites)
{
Console.WriteLine(site.Name);
}
}
If I put that code directly in a console application and run it, it will get and list the IIS express websites. If I run that app from an elevated command prompt, it will list the IIS7 websites. A little inconvenient, but so far so good.
If instead I put that code in a class library that is referenced and called by the console app, it will ALWAYS list the IIS Express sites, even if the console app is elevated.
Google has led me to try the following, with no luck.
//This returns IIS express
var mgr = new ServerManager();
//This returns IIS express
var mgr = ServerManager.OpenRemote(Environment.MachineName);
//This throws an exception
var mgr = new ServerManager(#"%windir%\system32\inetsrv\config\applicationhost.config");
Evidently I've misunderstood something in the way an "elevated" process runs. Shouldn't everything executing in an elevated process, even code from another dll, be run with elevated rights? Evidently not?
Thanks for the help!

Make sure you are adding the reference to the correct Microsoft.Web.Administration, should be v7.0.0.0 that is located under c:\windows\system32\inetsrv\
It looks like you are adding a reference to IIS Express's Microsoft.Web.Administraiton which will give you that behavior

Your question helped me find the answer for PowerShell, so if the Internet is searching for how to do that:
$assembly = [System.Reflection.Assembly]::LoadFrom("$env:systemroot\system32\inetsrv\Microsoft.Web.Administration.dll")
# load IIS express
$iis = new-object Microsoft.Web.Administration.ServerManager
$iis.Sites
# load IIS proper
$iis = new-object Microsoft.Web.Administration.ServerManager "$env:systemroot\system32\inetsrv\config\applicationhost.config"
$iis.Sites

CAUTION! Using this approach we have seen seemingly random issues such as "unsupported operation" exceptions, failure to add/remove HTTPS bindings, failure to start/stop application pools when running in IIS Express, and other problems. It is unknown whether this is due to IIS being generally buggy or due to the unorthodox approach described here. In general, my impression is that all tools for automating IIS (appcmd, Microsoft.Web.Administration, PowerShell, ...) are wonky and unstable, especially across different OS versions. Good testing is (as always) advisable!
EDIT: Please also see the comments on this answer as to why this approach may be unstable.
The regular Microsoft.Web.Administration package installed from NuGet works fine. No need to copy any system DLLs.
The obvious solution from the official documentation also works fine:
ServerManager iisManager = new ServerManager(Environment.SystemDirectory + #"inetsrv\config\applicationHost.config");
This works even if you execute the above from within the application pool of IIS Express. You will still see the configuration of the "real" IIS. You will even be able to add new sites, as long as your application runs as a user with permission to do so.
Note, however that the constructor above is documented as "Microsoft internal use only":
https://msdn.microsoft.com/en-us/library/ms617371(v=vs.90).aspx

var iisManager = new ServerManager(Environment.SystemDirectory + "\\inetsrv\\config\\applicationhost.config");
This works perfectly. No need to change any references