I have a blazor app that sometimes gets a ERR_CONNECTION_RESET on a specific dll and fails to launch.
This does not happen in every machine, and sometimes in the same browser but on different machines, it does not open also.
The dll in question is in the correct directory.
What troubles me more is the "randomness" of the error, since we are unable to find why in some machines it works and others it does not.
Here is a pic of the error.
Thanks to everyone that can help.
Related
we're trying to use a dll given to us by a different company, and on all development computer this dll is found fine and runs properly, but once we try to do the final build and publish it on one of our servers, the outside dll that we're usin gfrom this company is unable to be found and leads to the program crashing, any ideas for solutions and/or causes?
I am having some problems with my production asp.net v4.5.2 website when I add new dlls. I am developing on a standalone laptop with Visual Studio 2017 and I just added some telerik document processing library functions that need the PresentationCore and PresentationFramework dlls. On my development machine there was no problem, added the "add assembly" line to my web.config and added the reference in Visual Studio and it worked fine. I added the dlls to the bin folder on the production environment (2008r2 IIS 7.0), uploaded the new code and modified that web.config accordingly now it works but my users are randomly having controls and pictures not load and getting kicked out of the website with a 403 access is forbidden error. The users get kicked out after going through CAC authentication (production is a military server). Sometimes it's right after they login (CAC authenticate) sometimes there a few minutes into doing stuff and then bam, a control doesn't load or the 403 error pops. This happens in both Chrome and IE. The controls or pictures not loading generally are fixed with a refresh (not always though) but the 403 error the users have to reboot their machine to fix. I've even had them clear the browsing data (cache, cookies and ssl state) but they still have to reboot.
When I take those dlls out of the bin folder the problems go away. Google seems to always point to Visual Studio answers and the closest things I found here are adding custom .dll class library to asp.net/C# website and How do references work in ASP.NET WebForms websites (not web applications)? Which didn't help. I think you should also know that I have 2.5 years experience in professional coding and system administration and I am the Lead/Senior (and only) developer and the Sys Admin for this project, please use small words for me. Thanks for any help you can provide.
I figure out what was happening and it wasn't the dlls. Turns out the I was missing a CSS file which caused 404 errors and when enough of those piled up the web app would crash or IIS would give a 403 error. I found this by looking at the event logs for IIS on our production test site. It was so hard to find because that CSS was for 1 particular control and if you didn't navigate to the page with that control enough times it worked fine. I thought it was the dlls because I just added functionality to that control that required them and without that functionality the control was not used as much and so wasn't loaded enough times to cause the error.
Not sure why Visual Studio didn't say anything about the missing file but once I removed the call for that CSS file everything worked as expected. I took over this particular code recently and no other place in code are there custom CSS files so I never noticed the call for it. Luckily IIS is set to log everything.
The company I work for has recently decided to move to a ClickOnce deployment strategy for one of our internal applications that needs to be run by a hundred or so production computers. The previous strategy of building a .msi and installing worked fine between updates and we never experienced any problems after updates. Now that we have switched to ClickOnce we are experiencing a number of problems. After the initial install everything was working fine until we pushed out our first update. All of the computers successfully updated and ran that software fine for the day. The next morning when they were booted a number of the computers gave the error:
Could not load file or assembly "_______, Version=1.0.0.0. Culture=neutral, PublicKeyToken=null" or one of it's dependecies. The module was expected to contain an assembly manifest.
Where the blank is one of two C# dlls that is part of the application.
We never get these errors in development and I am unable to reproduce the issue on any computers I try. Even one of the production computers doesn't throw the error when I tried restarting it (hard reset and soft reset).
Here are some of the things we have tried:
Making sure the main application and all the dlls are built for any CPU as this seems to cause this problem often from our research. This has been verified by looking at the assembly information of the built executable.
Made sure all the dlls and manifest files were in their correct place in the ClickOnce folders, comparing them to working computers shows no real difference
It is not even all the computers that go down with each restart, it seems like a matter of chance, some are fine on a particular restart and others are not. These computers have all been imaged to be identical and none of the external dependencies have changed between the two builds so I am having issues finding any difference there.
Any insight from someone that has experienced similar issues and/or knows what could cause these issues in a ClickOnce-deployed application would be appreciated.
Some further details.:
Looking deeper into the particular dll that is having an issue that was on one of the computers it almost looks as if it is just a blank dll as it won't bring up any information on its assembly when I run a utility against it. However it is the perfect size that it should be so it can't be completely blank (408KB). Any clue why that could be? Why would ClickOnce download a blank dll when other computers had gotten the correct dll from the same place and the application had had the correct dll on the original run?
The way we have been 'fixing' this is by uninstalling and re-installing the software which basically fixes it for the day or until the system is restarted. Although we have hit a computer or two that even after a re-install will give the same error even though the initial install was fine.
Hopefully this can help.
I developed a web application which is working perfectly on my local (laptop), now, when I copied-pasted the .dll (which came from my laptop) and other .aspx files on another PC and browsing the web application on the localhost (new machine), I am encountering an error saying Server error in "/" application,
Parser error message: Could not load type 'namespace.of.my.library'
Additional info:
When I build/publish the .dll, it's only producing one dll file, so I am sure that I didn't missed anything when I copy-pasted the code into a different machine.
I also checked the framework version of the generated dll and the framework version of IIS and they are the same with my laptop.
And since the web page is producing this error, I don't know how to debug, I can't get any relevant info out of it.
Did I missed something?
Thanks!
I have a small application that includes two third-party DLLs, pjsipDll.dll and sipeksdk.dll. Both of these DLLs are set to True for Copy Local. When I publish the application and install it on a second computer running Windows 7, it loads the sipeksdk dll fine and then that dll tries to use something from pjsipDll and it errors out saying:
"Unable to load DLL 'pjsipDll.dll': The specified module could not be found."
If I install this clickonce deployment on my development computer it works fine.
I looked in the deployment directory in on both computers, both DLLs are present, all the files are the same. On both systems I'm running as an administrator.
Any ideas on what I might be missing?
Thank you,
Stateful
It's funny how you fix the problem after posting on StackOverflow. It appears I was using incompatible builds of the DLLs. I found an older version of each that were known to work together and everything started working.