CSLA 5.4 socket problem in Office Addin and Azure App Services #2071
Replies: 4 comments 2 replies
-
@RolandoTonin I converted this to a discussion, because it isn't clear yet that this is a defined work item for CSLA. There have always been challenges running .NET code inside of Office, Internet Explorer, and other non-traditional client environments. Not all of them load the .NET runtime the same way, often due to security sandbox constraints or other issues. As a result, it has not always been possible at all to run CSLA inside those strange environments. Sometimes there are workarounds, sometimes there are not workarounds. For example, to host CSLA in Internet Explorer, on startup, your code needs to register a helper so .NET can find types in memory, because IE somehow loads .NET in a way that works different from normal. I suspect that is what is happening with loading in Excel. Excel probably loads the .NET runtime in a special way for security reasons, and also to provide your code with access to the O365 APIs. I wish I could say that finding these workarounds is easy, but it is not. Back when I was figuring out that IE workaround (many years ago) I did a lot of Internet searching, talked to some Microsoft folks, and spent hours trying different things until I stumbled across a solution. You will probably follow a similar journey to find a workaround for Excel. |
Beta Was this translation helpful? Give feedback.
-
Thanks Rocky, this problem emerged after the migration from CSLA 4.11 to 5.4 both client side in excel and server side (app in azure). with csla version 4.11 everything worked fine.
Thanks a lot for your great work. Rolando
…________________________________
From: Rockford Lhotka <[email protected]>
Sent: Monday, January 25, 2021 9:16:56 PM
To: MarimerLLC/csla <[email protected]>
Cc: RolandoTonin <[email protected]>; Mention <[email protected]>
Subject: Re: [MarimerLLC/csla] CSLA 5.4 socket problem in Office Addin and Azure App Services (#2071)
@RolandoTonin<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRolandoTonin&data=04%7C01%7C%7C92ae1ceeebb047f00b7808d8c16e2a1e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472026179129586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BtSqJklRqMy9DoXDxyhIiyYKA0UZznz4pUxIJDDxBko%3D&reserved=0> I converted this to a discussion, because it isn't clear yet that this is a defined work item for CSLA.
There have always been challenges running .NET code inside of Office, Internet Explorer, and other non-traditional client environments. Not all of them load the .NET runtime the same way, often due to security sandbox constraints or other issues. As a result, it has not always been possible at all to run CSLA inside those strange environments.
Sometimes there are workarounds, sometimes there are not workarounds. For example, to host CSLA in Internet Explorer, on startup, your code needs to register a helper so .NET can find types in memory, because IE somehow loads .NET in a way that works different from normal.
I suspect that is what is happening with loading in Excel. Excel probably loads the .NET runtime in a special way for security reasons, and also to provide your code with access to the O365 APIs.
I wish I could say that finding these workarounds is easy, but it is not. Back when I was figuring out that IE workaround (many years ago) I did a lot of Internet searching, talked to some Microsoft folks, and spent hours trying different things until I stumbled across a solution.
You will probably follow a similar journey to find a workaround for Excel.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarimerLLC%2Fcsla%2Fdiscussions%2F2071%23discussioncomment-309732&data=04%7C01%7C%7C92ae1ceeebb047f00b7808d8c16e2a1e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472026179139578%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=885yZLeogLPm4Ye9SNHSqI9GzfrN9%2FJUHx%2F8vNOj2jo%3D&reserved=0>, or unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACKQZ3KFYPB4563FOYZX5A3S3XGTRANCNFSM4WSJS3DQ&data=04%7C01%7C%7C92ae1ceeebb047f00b7808d8c16e2a1e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472026179139578%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fLomXOmufb3Xa1yW5ihtYRWY8fQqA2u0a68E8MbZXys%3D&reserved=0>.
|
Beta Was this translation helpful? Give feedback.
-
In Client side (Excel AddIn), These lines of code work with CSLA 4.11
```c#
Csla.ApplicationContext.DataPortalProxy = typeof(Csla.DataPortalClient.HttpProxy).AssemblyQualifiedName;
Csla.ApplicationContext.DataPortalUrlString = "http://toninserverapp.azurewebsites.net/api/DataPortal/PostAsync";
```
After upgrade to CSLA 5.4, always in Client, the above lines have been replaced with the following (I used a different website until all work properly) :
```c#
host = new HostBuilder()
.UseCsla((config) =>
{
config
.PropertyChangedMode(Csla.ApplicationContext.PropertyChangedModes.Windows)
.DataPortal()
.DefaultProxy(typeof(Csla.DataPortalClient.HttpProxy),
"https://tonin360appservice.azurewebsites.net/api/dataportal");
//"http://localhost:1446/api/dataportal");
})
.ConfigureServices((hostContext, services) =>
{
services.AddLogging(configure => configure.AddConsole());
})
.Build();
```
The commented line link is replaced in local developing mode and it work.
Exception occurs in the following methods:
```c#
public async static Task<PersonaIdentity> GetPTIdentity(string username)
{
try
{
return await DataPortal.FetchAsync<PersonaIdentity>(username);
}
catch (Exception e)
{
string ex = e.ToString();
throw e;
}
}
```
Finally this is the exception object value:
```text
System.Net.Http.HttpRequestException: Si è verificato un errore durante l'invio della richiesta. ---> System.Net.WebException: Connessione sottostante chiusa: Errore imprevisto durante un'operazione di invio.. ---> System.IO.IOException: Impossibile leggere dati dalla connessione del trasporto: Connessione in corso interrotta forzatamente dall'host remoto. ---> System.Net.Sockets.SocketException: Connessione in corso interrotta forzatamente dall'host remoto
in System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
in System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
--- Fine della traccia dello stack dell'eccezione interna ---
in System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
in System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- Fine della traccia dello stack dell'eccezione interna ---
in System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
in System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
--- Fine della traccia dello stack dell'eccezione interna ---
in Csla.DataPortalClient.HttpProxy.<Fetch>d__27.MoveNext()
--- Fine traccia dello stack da posizione precedente dove è stata generata l'eccezione ---
in System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
in System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
in Csla.DataPortal`1.<DoFetchAsync>d__18.MoveNext()
--- Fine traccia dello stack da posizione precedente dove è stata generata l'eccezione ---
in System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
in System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
in Csla.DataPortal`1.<FetchAsync>d__26.MoveNext()
--- Fine traccia dello stack da posizione precedente dove è stata generata l'eccezione ---
in System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
in System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
in Csla.DataPortal.<FetchAsync>d__29`1.MoveNext()
--- Fine traccia dello stack da posizione precedente dove è stata generata l'eccezione ---
in System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
in System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
in System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
in Tonin.Common.Business.Security.PersonaIdentity.<GetPTIdentity>d__1.MoveNext() in D:\Dati\Source\Gestionale Tonin\Library\Common\Business\Tonin.Common.Business.Shared.CSLA\Security\PersonaIdentity.CSLA.cs:riga 26
```
Regards Rolando
|
Beta Was this translation helpful? Give feedback.
-
Hy Rocky,
I finally solved this issue. These are the steps:
1. I create a simple Controller on server side with GET method that return a test string
2. On Excel Addin I create a simple Http client method that call this GET
3. After deploy App services on Azure and run Excel I received the same exception. Consequently, the problem is not CSLA but Excel AddIn
4. SocketExcepiton was fired on GetAsync method of Http Client and message header is "....connection was forcibly closed by the remote host..."
5. I searched in google with these key and I found this asp.net - C# HttpClient An existing connection was forcibly closed by the remote host - Stack Overflow<https://stackoverflow.com/questions/46223078/c-sharp-httpclient-an-existing-connection-was-forcibly-closed-by-the-remote-host> where one of the answer is related on TLS that for .NET framework 4.6-4.7 must be set to TLS 1.0. In my Azure test App service these parameter was set automatically to TLS 1.2. I changed to TLS 1.0, restart App service and now all work...
thank you for the support and suggestions you have given me and which have allowed me to resolve this critical issue.
Rolando
Da: Rockford Lhotka <[email protected]>
Inviato: martedì 26 gennaio 2021 18:27
A: MarimerLLC/csla <[email protected]>
Cc: RolandoTonin <[email protected]>; Mention <[email protected]>
Oggetto: Re: [MarimerLLC/csla] CSLA 5.4 socket problem in Office Addin and Azure App Services (#2071)
Looking at the history of HttpProxy<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarimerLLC%2Fcsla%2Fcommits%2Fv5.x%2FSource%2FCsla.Shared%2FDataPortalClient%2FHttpProxy.cs&data=04%7C01%7C%7C4c4e290dfdd148b2e72408d8c21f95bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472788193393051%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FTMQmMWyk6eplm4ptcw9uP2m5aMtNv%2B6rw%2BlqdVMvW4%3D&reserved=0>, the only two things that seem like they could have changed behavior are
1. The HttpClient instance is now provided via DI, but is still just created by creating a new instance; but perhaps you should try adding HttpClient as a service at startup so you can configure the client object differently?
2. Support for optional compression was added, and that did change the HTTP headers being sent over the wire
The "worse case" scenario I can see, and something you might want to try, is to copy the HttpProxy class from 4.11.2<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarimerLLC%2Fcsla%2Fblob%2Fv4.11.2%2FSource%2FCsla.Shared%2FDataPortalClient%2FHttpProxy.cs&data=04%7C01%7C%7C4c4e290dfdd148b2e72408d8c21f95bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472788193403038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C62bOi71nBNNauYRJWbhN%2FwlA1SgoB%2Buor197tRoZnk%3D&reserved=0> into your project and configure the data portal to use that older version of the code.
-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarimerLLC%2Fcsla%2Fdiscussions%2F2071%23discussioncomment-312094&data=04%7C01%7C%7C4c4e290dfdd148b2e72408d8c21f95bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472788193403038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VYHectHzoqNOkH7IDfkfGDREIuvlDUZYkjr%2Ft98qRg0%3D&reserved=0>, or unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACKQZ3M2K44MKKOVL4456HDS333ODANCNFSM4WSJS3DQ&data=04%7C01%7C%7C4c4e290dfdd148b2e72408d8c21f95bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637472788193413038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bk9tigmmILo6RKQAnJkKMgzV%2BUS8YE5dG0xUDy%2BAoi8%3D&reserved=0>.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
A UI client implemented as Excel AddIn that call a App Web Service in Azure not work. When the first call from client to Azure App Service firead an exception "Connection lost by the remote server". Instead it work fine, with the same code in desktop WPF app, in AutoCAD. Also if I try the Excel AddIn with a localhost connection it work fine. Attached you can find a reporduced version for Project Tracker. Also it work fine in localhost platoform but I don't try with https://ptrackerserver.azurewebsites.net/api/dataportal because there is a missing syncronization CSLA Version Library (my version is 5.4 and on Azure is 5.1 and I cannot log in to azure App to change it.
Version and Platform
CSLA version: 5.4.0
OS: Windows, Excel 365
Platform: WPF AddIn in Excel
Code that Fails
in ProjectTracker.Ui.ExcelVSTOAddIn, ThisAddIn.cs file, ThisAddIn_Startup method.
ProjectTracker.Ui.ExcelVSTOAddIn.zip
Beta Was this translation helpful? Give feedback.
All reactions