This is my first Stack Overflow question so apologies if this isn't great...
I'm sure this is something either super simple I am missing or something very complex that I've gotten myself into, but I am using ClickOnce for the first time to create an automated updater for a company application I developed.
The application itself was originally written in VB but I have translated it into C#. We use this to automate a database of assets, which changes very frequently. I have been tasked to allow it to complete automated updates to keep from confusing some of the techs with uninstall/reinstalling the application weekly.
I volunteered to make an FTP server using a personal server machine I use at home. Normally this machine would be used for local networking but I've wanted to create an FTP server for some time (this is my first FTP server too).
So I went on my way, set the publish location for the build to ftp://[IP.ADDRESS]:21/Folder/Subfolder and the Installation folder URL to http://[IP.ADDRESS]:21/Folder/Subfolder
Long story short, when I try to test an update (changing only the assembly version), I am an error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The server committed a protocol violation.
I did some research and tried adding an SSL certificate and changed the update path to https://[IP.ADDRESS]:21/Folder/Subfolder/ then tested that. This time around, I get this error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. --> System.IO.IOException: The handshake failed due to an unexpected format.
I cannot tell if this is progress or if I moved backwards here LOL. I've been jumping back and forth and going to many threads to try to figure out where this is going wrong. I'm also having a pretty tricky time finding out if this is an error with how I've set up ClickOnce or if this is an error in how I have set up FTP with IIS.
Apologies if this is not enough information, I can provide more if necessary. Also apologies if this is too much information! Any help or guidance is appreciated!
I'm guessing you're working for a small company and infrastructure/resources are at a premium. With that in mind I'll offer some suggestions:
Does your company have a network shared drive? I don't like ClickOnce, but I have deployed it to network shares in the past with success. This has the benefit of you not needing to deal with security.
Have you considered migrating this to a web application? Web development seemed really daunting when I was a native app developer, but with Blazor and ASP.NET Core it's become a lot more accessible. This would completely get rid of the need for updating the application.
Consider an alternative deployment route. ClickOnce is not incredibly well supported.
I'd be remiss if I didn't throw a red flag on security. FTP is a very old protocol and is basically insecure by design. Hosting it on your home server means that you're transmitting the app over the public internet... What would happen if someone outside your company installed the application?
Related
I have a c# app that exports data from the database to the user's Exchange Calendar, using Microsoft.Exchange.WebServices (15.0.0.0). My app is DotNet 4.5.2 and I use Visual Studio 2013.
The app has been working fine for a year, and even now works 95% of the time. The app runs constantly on machine that I am logged into and monitor. This is a low volume process, perhaps 50 items get exported per day at most.
Every couple of days, the program will give this error:
"The request failed. Unable to connect to the remote server"
when the app is attempting to create an EWS connection to the server.
It will do this for maybe 10-20 items. So I shut it down, run it again, and it works perfectly fine on all the records that failed before.
This is my first EWS app, but I've been programming 30+ years and do have somewhat little knowledge of internet based apps.
Any helpful information or suggestions would be greatly appreciated!
Thank you kind people!
The internet often works, but should never be considered reliable. Anything using it should handle errors, and retry if desired. The classic approach is Exponential backoff. Its possible something nasty is going on, like your ISP swapped your IP address, or just intermittent failure. I don't know anything EWS specific, but there may also be sources of flaky issues there as well.
It is not a specific problem because I have more than one experience that fiddler save my app.
A recent example:
I had an excel addin app write in C#. In the app I had a httpclient to connect to my server through ssl. And I ignored the certification in my code explicitly.
The app always worked well(I mean the connection part), but one day in a QA environment, it failed in no causes. The connection seemed to be blocked for long long time.
Coincidentally, we opened the Fiddler and tried to grab some http. Then everything worked fine.
(Fiddler may do something in the middle)
Then after closing Fiddler, we cannot recreate the problem because all things went back to fine again.
(Fiddler change something permanently!)
Here are some clues:
We use the normal C# http clients System.Net.Http .
Our server is ssl (https, but we must ignore the cert)
The app was good in the same environment at frist.
The lastest change is about the localization, and the test enviroment changed the windows local and language.
We are under a company network, using a proxy in the example above.
The failure is not the whole connection module, but a specific request.(In our case, a request that post two small xml files including excel itself)
Please give us some hint and guess, so we can feel better on this mystical problem.
How long is a "long long time" exactly?
Fiddler does not make any persistent changes to the system; if you start and stop it, the system is returned to the prior configuration. I suppose it's remotely possible that if some configuration setting were corrupt before Fiddler ran, that corruption wouldn't be replicated after Fiddler attempted to reapply it, but we don't know of any such "corrections."
This article describes some of the things folks find unexpected in terms of Fiddler "magically" fixing things while it runs.
We have an instance of SQL Notifcation Services for which we have written a custom delivery channel. We had this process up and running in our QA environment running Windows Server 2003 with SQL Server 2005. It took a little bit of tweaking to the get the custom DLL trusted however we got it all working.
We have since deployed this code to our Live environment. This runs Windows Server 2008 with an Instance of SQL 2005 for Notification Services but then we have an instance of SQL 2008 which hosts the actual DB instance for Notification Services. Notification Services works as it should however we cannot get the custom DLL to be trusted as a result the custom delivery channel won't work. We simply get the error
That assembly does not allow partially trusted callers
We have tried using the .NET configuration utility and caspol.exe to give the .dll full trust with no luck at all. The .dll is compiled as a .NET 2 dll as notification service requires this.
We are pretty much out of ideas at the moment and hoping someone can suggest something?
We have managed to fix our issue. It would appear that Windows Server 2008 is stricter in its implementation of code access. By giving granting access to the .DLL by it's strong name rather than it's path allowed Notification Services to access the code.
Notification Services was not at fault.
I think you have one of two choices:
Embrace SQL 2008 and get rid of Notification Services because it was deprecated. Use Reporting Services or SSIS to do what you need.
Revert back to SQL 2005.
IMHO, I'd go option 1. Continuing to build with deprecated tools is going to quickly find you in a situation where support (community or vendor) is going to be extremely hard to come by.
update
This was too long for comments.
Not to beat your head too much, but continuing to develop applications for a technology that was EOL'd (end of life) over 3 years ago was the first mistake. The EOL statement was made quite public.
The second was having a QA environment that is radically different from production. Before deploying anything to production, the QA environment should have been identical... same type of hardware, same OS's, same server versions and patch levels. Otherwise QA is a joke, as you've found.
Now, as to the "resolution", there really is only one path: Revert your production environment back to SQL 2005 with the appropriate patches in place.
I wish you luck.
I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.
I am trying to solve a persistent IO problem when we try to read or write to a Windows 2003 Clustered Fileshare. It is happening regularly and seem to be triggered by traffic. We are writing via .NET's FileStream object.
Basically we are writing from a Windows 2003 Server running IIS to a Windows 2003 file share cluster. When writing to the file share, the IIS server often gets two errors. One is an Application Popup from Windows, the other is a warning from MRxSmb. Both say the same thing:
[Delayed Write Failed] Windows was unable to save all the data for the file \Device\LanmanRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elswhere.
On reads, we are also getting errors, which are System.IO.IOException errors: "The specified network name is no longer available."
We have other servers writing more and larger files to this File Share Cluster without an issue. It's only coming from the one group of servers that the issue comes up. So it doesn't seem related to writing large files. We've applied all the hotfixes referenced in articles online dealing with this issue, and yet it continues.
Our network team ran Network Monitor and didn't see any packet loss, from what I understand, but as I wasn't present for that test I can't say that for certain.
Any ideas of where to check? I'm out of avenues to explore or tests to run. I'm guessing the issue is some kind of network problem, but as it's only happening when these servers connect to that File Share cluster, I'm not sure what kind of problem it might be.
This issue is awfully specific, and potentially hardware related, but any help you can give would be of assistance.
Eric Sipple
I've heard of AutoDisconnect causing similar issues (even if the device isn't idle). You may want to try disabling that on the server.
I am having similar problems:
writing to a machine that is also part of a Windows 2003 R2 NLB cluster sometimes results in "Delayed Write Failed" or "the semaphore has timed out" or "the specified network name is no longer available"
this is reproducible for the same files, even after rebooting all machines involved
if I rename the problem-files (some of which are quite small), the problem remains
if I write the files to another location (fysical disk) on the same machine, the problem remains
I uninstalled all anti-virus software, problem remains
I have reset the tcp-ip stack, problem temporarily disappears, but after some time the problem returns for the same files
PARTLY SOLVED the problem:
I deleted (not stopped) the host from the NLB cluster. Problem solved.
Seems to have to do something with writing to a share on a server that is also part of a network load balancing cluster
I have not yet found other people posting NLB cluster related file write problems. However, I did find many posts complaining about similar problems, none of which seem to have been solved.
Anne
I've seen other people reporting the "delayed write failed" error. One recommendation was to adjust the size of the cache, there's a utility from sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx) that will allow you to do that.