0
votes

This has been bugging me all day and I have yet to figure out why this is happening.

Basic scenario

  1. Created a new Service Fabric Application with an ASP.NET Core service and added support for returning MVC views so that it can act as the UI for my SF App.

  2. Added an Actor service for users to the solution which created the UserActor and UserActor.Interfaces projects and ensured that the Interfaces library targets x64 as required by SF.

  3. Defined a Task<UserProfile> GetProfileData() method on the UserActor where the UserProfile type is a concrete class defined in the Interfaces project with the [DataContract] and [DataMember] attributes so that it can be serialized (all members are primitives).

  4. Added a project reference to the UserActor.Interfaces from the ASP.NET Core project so I could create the actor proxy and invoke the method.

  5. Added the code in the ASP.NET Core Controller class to connect to the actor instance and invoke the GetProfileData method

At this point, I receive the following compiler error:

error CS0246: The type or namespace name 'UserProfile' could not be found (are you missing a using directive or an assembly reference?)

The relevant lines of code are as follows:

using UserActor.Interfaces;

var user = ActorProxy.Create<IUserActor>( new ActorId( model.email ), FabricAppUrl );
UserProfile profile = user.GetProfileData().Result; // compiler error here

If I hover over the UserProfile type on the last line, Visual Studio shows me it sees the type as UserActor.Interfaces.UserProfile and doesn't show any errors in the editor. It's only when I compile that this error shows up.

I didn't receive this error when trying to return a primitive type and it had no problem resolving the IUserActor interface for the Actor Proxy either.

Does this have something to do with the fact the the Actor projects are standard .NET projects and the ASP.NET Core project is compiled using dotnet build (set to .NETFramework,Version=v4.5.2; not dotnet core).

I also noticed in the build output that the ASP.NET Core project is building as 'Debug Any CPU' while all of the other projects are set to 'Debug x64'. If this were the issue I would expect to receive an error about mis-matched architecture types, but I'm not getting that either.

How can I resolve this? Should I be returning the data from the Actor in a different manner (such as json serializing it before returning it as a string primitive)?

Edit 1:

The code sample above was too simplistic. The 2 compiler errors I am seeing are around the type being passed to a helper method in the same controller as follows:

private bool TryGetUserProfile( LoginModel model, out UserProfile profile )
{
    var user = ActorProxy.Create<IUserActor>(new ActorId(model.Email), FarbicAppUrl);
    var profile = user.GetProfileData().Result;

    return !string.IsNullOrEmpty(profile.Name);
}
1
Did you try to replace UserProfile by var ?Kalten
Is the class UserProfile marked as public?LoekD
@kalten using var sorta helps, but the lines called out by the compiler are where I am try to pass the type to another method in the same controller (example above was simplified somewhat). Added another example to my question.KyKo
@LoekD yes, the class is a standard public class with a constructor (not a default) attributed with [DataContract] and several get/set auto properties attributed with [DataMember].KyKo
Do you have this in the project.json? "runtimes":{ "win10-x64":{} },LoekD

1 Answers

2
votes

OK, after starting the whole scenario out on a different machine I found what the problem is and believe it to be a Microsoft tooling issue. Here are the steps to reproduce the problem along with what needs to be done to correct it.

  1. Create a new Service Fabric project and select ASP.NET Core as the service. If prompted, select the Web Application Template (but I think this would be an issue if you selected the Empty or Web API templates as well). If you debug this, it will work just fine (provided you have a local cluster setup).

  2. Add a new Actor Service to the solution. This will create the UserActor and UserActor.Interfaces projects for you. If you try to compile at this point, you will receive the following error message:

C:\Program Files (x86)\MSBuild\bin\Microsoft.Common.CurrentVersion.targets(724,5): error : The OutputPath property is not set for project 'UserActor.Interfaces.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='AnyCPU'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform.

Checking the Configuration Manager shows that there is only an 'x64' target defined for the project. To get around this, use the Configuration Manager and add a new 'AnyCPU' target and copy it from the 'x64' target. Ensure that the target platform is still set to 'x64' for the interfaces project before closing the Configuration Manager since Service Fabric requires x64 assemblies.

  1. Now when you compile, you will receive the following error message:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(262,5): error : C:\...\Web error CS0006: Metadata file 'C:\...\UserActor.Interfaces\bin\Debug\UserActor.Interfaces.dll' could not be found.

The clue here is that the web project is looking in the OutputPath location defined for the 'AnyCPU' target and not the location defined for the 'x64' target (bin\x64\Debug). If you manually edit the interfaces project file and set the OutputPath for the 'AnyCPU' target to the same path as the 'x64' target, everything will compile properly.

You can also deploy the project and everything will work as it should. I'm not sure which target file from Microsoft has the problem in it, but it could be both. I'll look into reporting this as a bug with Microsoft in the hopes of getting it resolved (still present with the latest SDK released on 2/3/2017).

The reason the UserProfile type couldn't be found for me was because I had previously built the solution with the wrong OutputPath set before I added the UserProfile class to the project so the compiled DLL that MSBuild was looking at didn't contain the type. If I had removed the bin & obj folders from the solution, it would have become obvious where the problem was right away.