Cannot deploy fabric application

[o-e]

We are (from Visual Studio 2015) trying to deploy a little solution (with a stateful actor) to the local machine, but cannot get through the deployment phases. The following error occurs:

Finished executing script 'Set-LocalClusterReady'.
Time elapsed: 00:00:01.8736772
Started executing script 'Deploy-FabricApplication.ps1'.
. 'C:\Users\My name\Desktop\TestProject\TestProject\Scripts\Deploy-FabricApplication.ps1' -ApplicationPackagePath 'C:\Users\My Name\Desktop\TestProject\TestProject\pkg\Debug' -PublishProfileFile 'C:\Users\My Name\Desktop\TestProject\TestProject\PublishProfiles\Local.xml' -DeployOnly:$false -UnregisterUnusedApplicationVersionsAfterUpgrade $false -ForceUpgrade $false -OverwriteBehavior 'SameAppTypeAndVersion' -ErrorAction Stop
Test-ServiceFabricApplicationPackage : Could not find a part of the path 'Microsoft.AspNet.PageExecutionInstrumentation.Interfaces.dll'.
At C:\Program Files\Microsoft SDKs\Service Fabric\Tools\PSModule\ServiceFabricSDK\Publish-UpgradedServiceFabricApplication.ps1:107 char:34
+ ... tionSuccess = (Test-ServiceFabricApplicationPackage $AppPkgPathToUse)
+                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Test-ServiceFabricApplicationPackage], DirectoryNotFoundException
    + FullyQualifiedErrorId : System.IO.DirectoryNotFoundException,Microsoft.ServiceFabric.Powershell.TestApplicationPackage

Some version information:

Microsoft.AspNet.PageExecutionInstrumentation.Interfaces: 1.0.0-rc1-final Microsoft.ServiceFabric: 4.4.87-preview Microsoft.ServiceFabric.Actors: 1.4.87-preview Microsoft.ServiceFabric.Data: 1.4.87-preview Microsoft.ServiceFabric.Services: 1.4.87-preview

[automatonic]

While I am not certain this is the correct place to log an issue (documentation site) I can confirm the behavior. The only workaround I have found is to not customize the service name when adding the service. That is, when adding an ASP.NET 5 WebApp to service fabric, keep it named as its "Web1" default.

"Web1" will work fine. Any other name i have tried fails with this same issue...complaining about the location of Microsoft.AspNet.PageExecutionInstrumentation.Interfaces.dll

[automatonic]

I have posted this on the service fabric forum: https://social.msdn.microsoft.com/Forums/azure/en-US/853c34e2-9ff4-477c-b042-9012a1338435/testservicefabricapplicationpackage-fails-if-aspnet-5-template-isnt-named-web1?forum=AzureServiceFabric

[automatonic]

After a bit more experimentation, it appears the problem (for me) was using a name with "." in it. "Web1", "Web2", and "Taco" will work. "Some.Dotted.Name" does not.

[jameskeongchen]

Oh I was also getting this issue with the "." (dot) in my naming of a service in ASP.NET 5. Hopefully this bug can be addressed in the next SDK update. Thanks for your post it helped me! (it was a tricky one since the VisualObjects.WebService was working in ASP.NET4.5)

[automatonic]

@jameskeongchen i think it may be something more simple. I was unable to add a project name that had more than 4 characters. It appears that some long paths are generated via that string, which makes certain files in the build process unreachable. "Portal" does not work as a project name, but "Port" does. There may be a further issues with "." in the name, but i think this was the primary issue. Note that the forum post listed above has an official ms response that sheds a bit more light.

[jameskeongchen]

@automatonic yes agreed - thanks for sharing; resolved to using three letter names for services for now :+1:

[another-guy]

@automatonic Thanks for the hint. This is a crazy limitation!

[masnider]

Hi Folks, First, thanks everyone for sticking to it. Yeah, it's a real pain. Comes mainly when folks are using the ASP.net projects. In core Service Fabric services we've made sure to switch to UNC paths so that you won't see this when using just services or actors on their own. Just so that everyone knows we're also working closely with the ASP.NET team to eliminate some of these pain points that lead to lots of long paths. Until then, yeah, short names for things like your application types are the way to go. Also for the record we don't know of any specific issues with periods in the names of things, so if someone has a repro for that outside of the long path issues we'd love to see it (well, would appreciate the repro so we can find and fix any bugs).

[another-guy]

@masnider Thanks for confirming you guys are aware of this behavior/limitation! I spent more than half of the day fighting this thing. I recommend you folks update your documentation with a small note about this issue. Specifically, the intro page: https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-add-a-web-frontend/

[seanmck]

@another-guy Yes, we will get the doc updated to call this out and hopefully get the fix out very soon. Apologies for the inconvenience.

[masnider]

PR in flight :)

[arankun]

i also came across this issue. other than limiting the project name to 4 characters, i also made sure that the project path is short as well (eg. c:\sf)

[masnider]

Yes. Limiting the paths can also help. Also just FYI, most people are reporting this as an issue mainly when including the ASP.NET project type. There are many changes coming to ASP.NET which should really help out here (they're flattening their directory structures and making several other changes). A lot of these coming changes like the ones in ASP.NET RC2 are being incorporated as soon as they are public in examples by my coworker David over here: https://github.com/weidazhao/Hosting

[venky085]

@masnider I'm facing the period issue. If the assembly name has periods, then the application will not run. I see the error "The PowerShell script failed to execute. See the Output window for details." in the error window and then when I check the output window I see the error "Register-ServiceFabricApplicationType : The EntryPoint abc.exe is not found.".

[eloekset]

For other readers googling this cryptic error, it can also occur if <EnvironmentOverrides .../> is removed. I was adding config overrides and removed an environment override that wasn't used anyway. I succeeded deploying again after adding back some content to the XML element:

[MalithRukshan]

![capture](https://user-images.githubusercontent.com/20617431/38916276-5ba90056-4304-11e8-8e05-2512d6c55c51.PNG