I have a windows application installed and working perfectly fine.
Something weird came up, the test scenario is if I rename the config file from the original name which is:
Model Label PC Client.exe.config
...to:
xxxModel Label PC Client.exe.config
...and click the .EXE file on the application folder / path where i installed it, it works as expected.
But when I clicked the shortcut icon of this application on the desktop, it shows a pop up that installs a new copy of the correct config file name.
please refer to the screenshot , any idea how to prevent this from happening? or is this really the behavior?
OP:
"any idea how to prevent this from happening?"
For installed apps, it is by design. Essentially you have removed an installed file and so the installer tech will kick in to recover it as if nothing happened.
Now technically you could get around that auto-recovery by not using MSI tech to install your app trusting instead on good-ol' XCOPY but then again, renaming/moving/deleting the file may break the app because this time there is no auto-recovery!
Additionally .NET apps expect to find a .config file matching the same name as the executable so you shouldn't go renaming/deleting/moving it in most scenarios.
I have a small application, it launches properly without debugger and all the features work except one which uses IronOcr (package from NuGet package manager). When I try to use this feature the program just closes.
When I launch this application from within visual studio, everything works fine. No errors and all features work. I get the same result if I run it and attach the debugger to it afterwards. However if I run the exe by launching the exe /bin/release and do not attach the debugger it crashes when I try to use the feature involving IronOcr.
I tested this on a virtual machine, same results with/without debugger. I then tested it on a different computer (fresh install of windows only having VS installed) it gave me this error if debugger is attached:
System.IO.FileNotFoundException: 'Could not load file or assembly 'IronOcr, Version=2021.2.1.0, >Culture=neutral, PublicKeyToken=c2cbcea5ea3f6d8d' or one of its dependencies. The system cannot >find the file specified
I've spent the last few days looking up a reason for this but I have not found one so far that fixes the issue.
What is confusing me the most is:
I assume the error that causes the program to close is the same error that causes it to give this error on the different PC. When I run it through VS it has no issues (it finds the file?) but running it from the exe it cannot find the file. I'm not moving the exe, just running it where it is in the bin/release.
I'm hoping this program will be able to run as a standalone exe.
I am still relatively new to c# and VS, the error may be glaringly obvious, or I may be using the wrong words causing me to not find a solution.
probably a bit too late, but your problem certainly comes from the fact you're using the free licence of IronOCR. It seems that this one only works when the debugger is attached.
If you catch the exception, you get that message:
IronSoftware.Licenses.Exceptions.LicensingException: IronOcr must be
licensed for deployment outside of the Visual Studio development
environment. https://ironpdf.com/licensing
In my opinion this is too restrictive for proper evaluation, so I gave up trying to use it.
Make sure IronOcr.dll is exist at same directory as your executable file.
Try to execute your application from Bin/Debug and see if it runs ok or not.
Check to see if IronOcr.dll exist in Bin/Debug but does not exist in Bin/Release. if so then copy it from Bin/Debug to Bin/Release.
I have a program that has been working just fine, however when I made a small change to the way the program loads from its ini, the zipping function stops working. I stepped through the program and found the error to be occuring on the following line:
var fs = File.Create(zipPath);
fs.Write(emptyZip, 0, emptyZip.Length);
fs.Flush();
fs.Close();
var sc = new Shell32.ShellClass();
var srcFlder = sc.NameSpace(program.Path); //THIS LINE
var destFlder = sc.NameSpace(zipPath);
var items = srcFlder.Items();
destFlder.CopyHere(items, 20);
System.Threading.Thread.Sleep(500);
ZippedPrograms.Add(zipPath);
I double checked the variables program.Path and others being sent to the ShellClass(), and they are not null or empty. This is the actual error that pops up when the program gets to this line:
Doing some googling I find that apparently the Shell32.dll I have referenced in my program does not work right with 7 (or server 2008, the target environment), and I needed to reference the XP version instead (52kb versus 48kb dll size). One of the links where I found this info: click me.
So I created a virtual machine and installed WinXP Professional on it, and navigated to C:\WINDOWS\system32\ and copied the Shell32.dll located there to my host computer. Strange enough, the DLL is ~8mb in size rather than the 52kb I was expecting. When I add it as a resource from VS2012, I browse to the copied file and add it (with copy local), but then for some reason it ends up being 48kb in size and the program continues to crash at the above mentioned line.
I have tried using DotNetZip along with other C# libraries for zip management, and for some reason they never work properly (creating corrupted ZIP files, not creating them at all, refusing to add random files/folders to the archive, etc). Before this issue the program was working flawlessly, so more than anything I am confused as to why all of a sudden it is not working and why the Shell32.dll is not A) the 8mb version I reference, and B) 'stripped down' to 48kb. On top of that, I checked the current deployment of the program, which lacks some features of the current version, among other things, and the DLL there is the 48kb size, and this particular deployment has worked with no problems.
I should also mention that I am currently running Windows 8 Pro, and developing in VS2012. The deployment environment is Windows Server 2008 R2. I originally wrote this program in VS2010 on Windows 8 Ultimate. When I opened the project for the first time in VS2012, there was no upgrade dialogue. All OS's listed (except WinXP Pro) are x64.
Has anyone had any experience with these issues/happenings? Any insight/tips/solutions will be greatly appreciated.
Thank you!
Dragging across an outdated system dll to a newer version of Windows is something that's just bound to fail, especially if it's (as in this case), a COM interop DLL. If Windows 8 is running a COM service, it's going to be running it with its "own" version of the DLL. If you then try to interact with it using an interface DLL for a different version, you'll get an interface mismatch. As you've seen, E_NOINTERFACE.
You're trying to use a version 6 DLL to communicate with a version 8 service. It's bound to run into problems.
The difference in size might have something to do with Visual Studio stripping the deployment DLL down to just the interfaces, instead of including all the implementation.
I've created a WPF Window with a lot of buttons, each of them run a different program. To run MS Word, for instance, I used:
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE");
But when I try to run the Windows 7 Snipping Tool the same way it doesn't work. It was supposed to be like this:
System.Diagnostics.Process.Start("C:\\Windows\\System32\\SnippingTool.exe");
I'm sure the path is correct, but always appears a message saying the file wasn't found. I would like to know why is this happening.
Important: I use Windows 7 64 bits.
Use this:
// if the build platform of this app is x86 use C:\windows\sysnative
if(!Environment.Is64BitProcess)
System.Diagnostics.Process.Start("C:\\Windows\\sysnative\\SnippingTool.exe");
else
System.Diagnostics.Process.Start("C:\\Windows\\system32\\SnippingTool.exe");
The problem is in your build platform (x86) and the automatic redirection of the folder C:\Windows\System32\ on 64-bit OS'es.
Basically, for several reasons, in vista/windows 7 64-bit OS'es when a 32 bit application try to access to C:\Windows\System32\ it is automatically redirected to the folder called C:\Windows\SysWOW64\. Hence, you cannot start snippingtool.exe because it is not present in that folder.
The only way is to use C:\Windows\sysnative\ and bypass the redirection.
My psychic debugger tells me that you are running a 32-bit program on a 64-bit version of
Windows, so your call to %WINDIR% (C:\Windows) is actually being re-routed to C:\Windows\SysWOW64.
Use the environment variable instead of hard-coding paths to directories that may move around depending on the environment and/or Windows version..
You should use an environment variable instead. Likely you are running it on a 64 bit system and C:\Windows\System32\ is getting redirected.
I am debugging codeplex simple project. I am using
VSTS 2008
C#
Windows Vista x86 Enterprise.
I have not modified any code of this codeplex project, and just press F5 to run VideoPlayerWeb project.
The current issue I met with is error message --
Unable to connect to ASP.Net Development Server.
Here is my screen snapshots when clicking F5. Any ideas what is wrong?
I had this problem with VS 2010, and it was as simple as terminating the "WebDev.WebServer40.EXE" process. Although the icon was no longer showing in the system tray, the process was still running.
Could be a number of things...try these (check the last one first)...
Disable IPv6
Make sure there isnt an edit in the
hosts file for localhost
Check firewall/virus settings to allow connections to/from
devenv.exe
If you can preview in the browser
make sure the URL in the browser uses
the same port number as the port
number shown in the ASP.NET dev
server taskbar icon.
Try setting a fixed, predefined port
in project properties
I got these from a couple of forums elsewhere, hopefully they can help. Good luck. Let us know what works and some more about your environment (firewall, anti virus etc) can help as well.
Under project settings, try specifying a different port like 64773 for example. I have encountered this issue many times and it has always worked for me.
It cause the already that project port server is running in the current thread. You need to end process using task manager.
Follow below step:
Pres Ctrl+Alt+Delete (Task Manager)
find the asp.net server like
WebDev.WebServer40.exe for VS2010
and press end process.
Now u continue with vs2010 run
button
I went to the project file and changed the development server port to 1504. Well 1504 worked on another project for me, so I went with that. Hope this helps.
I have tried all of the above solutions and others from other websites too but with no luck.
What worked for me, was to rename or delete the applicationhost file:
C:\Users\User\Documents\IISExpress\config\applicationhost < rename or delete.
That is very odd! I hate to suggest something as simple as restarting Visual Studio...but that is what sounds like the best first place to start. Also, check your project settings. As you said that you just downloaded this and tried to run it...perhaps the solution/project is not set up to use the Casini server that is shipped with Visual Studio?
Here are the steps
'Website' Menu in your visual studio ide.
select 'Start Options'
enable 'Use Custom Server' radio button.
Enter any URL you desire similar to 'http://localhost:8010/MyApp'
Note1: you can use any port number not only '8010' but not designated port numbers like 8080(tcpip),25(smtp),21(ftp) etc.,
Note2: you can use any name not only 'MyApp'
This solution works for sure unless your WebDev.Webserver.exe is physically corrupted.
Error
1) Unable to connect Asp.net development server ?
Answer: No way find for that error
Try 1)
Step 1: Select the “Tools->External Tools” menu option in VS or Visual Web Developer. This will allow you to configure and add new menu items to your Tools menu.
Step 2: Click the “Add” button to add a new external tool menu item. Name it “WebServer on Port 8010” (or anything else you want).
Step 3: For the “Command” textbox setting enter this value: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\WebD ev.WebServer.EXE (note: this points to the
web-server that VS usually automatically runs).
Step 4: For the “Arguments” textbox setting enter this value: /port:8010 /path:$(ProjectDir) (or any port you like)
Step 5: Select the “Use Output Window” checkbox (this will prevent the command-shell window from popping up.
Once you hit apply and ok you will now have a new menu item in your “Tools” menu called “WebServer on Port 8010”. You can now select any web project in your solution
and then choose this menu option to launch a web-server that has a root site on port 8010 (or whatever other port you want) for the project.
You can then connect to this site in a browser by simply saying http://localhost:8010/. All root based references will work fine.
Step 6: The last step is to configure your web project to automatically reference this web-server when you run or debug a site instead of launching the built-in
web-server itself. To-do this, select your web-project in the solution explorer, right click and select “property pages”. Select the “start options” setting on the left, and
under server change the radio button value from the default (which is use built-in webserver) to instead be “Use custom server”. Then set the Base URL value to be:
http://localhost:8010/
Obviously I don't know if this is the problem you had but definitely it is something similar, essentially the problem should be that the same port used by your
Development Server is not available because it is already used by another web server.
Try 2)
Here are the steps
1. 'Website' Menu in your visual studio ide.
2. select 'Start Options'
3. enable 'Use Custom Server' radio button.
4. Enter any URL you desire similar to 'http://localhost:8010/MyApp'
Note1: you can use any port number not only '8010' but not designated port numbers like 8080(tcpip),25(smtp),21(ftp) etc.,
Note2: you can use any name not only 'MyApp'
This solution works for sure unless your WebDev.Webserver.exe is physically corrupted.
Both of not worked after that Windows repair option remain
My solution was to turn off Internet Connection Sharing on my wireless adapter, after which it immediately worked. I made no other change. I suspect ICS's DHCP server was interfering.
Try commenting out the following line, if it exists, in your hosts file (%windir%\System32\drivers\etc\hosts):
::1 localhost
This worked for me using Visual Studio 2008 SP1 on Vista Ultimate x64 SP2.
I got this problem a couple of times and done different things to fix it. When I got it this time all I did to stop getting "unable to connect to asp..." error, was rename the web app folder directory from xpCal to xpCal2. I also tried moving the web app directory to a different directory from C:users\<me>\desktop\ to C:\users\<me>\desktop\new folder and it also worked.
I don't know why it worked, does VS 2010 keep information about web apps seperate from web apps folder.
In my case, when I had the ASP.NET Development Server crash, one thing that worked was to change the port for the project.
I suspect what happened was when the web server crashed it did not release a lock on the port. Even though it was not running in Task Manager, something was blocking a new instance of the web server from starting again on the original port. Changing the port was a decent enough work around. I could have rebooted, but who has time for that, right?
Details: Windows 7 x64, VS2010, .NET Framework 4.0, ASP.NET web site using the built in web server to VS2010.
BTW, I would be a little cautious with replacing the WebDev.WebServerServer.EXE as suggested in other posts. If that file has been corrupted then you have bigger problems with your OS.
hi
Just change the asp.netweb development server port from automatic to a specific port
e.g 8010
That's what worked for me
1) not reflecting HttpContext in class file ?
Answer:-Most of the time when using this syntax in class file is not working
we have to add reference then it work in class file
example using system.web write this syntax in class file
System.Web.HttpContext(HttpContext is not reflecting )
after that i add refrence system web than it reflect
None of the above solutions worked for me, but I did find one that worked: opening up the Administrative Tools/Services window and stopping the "WebClient" service. It's something of a pain to have to disable it when trying to work with my code, but it's easier than the logging off and back on I used to have to do.
--Problem Definition
------ whenever we debug our project (either by pressing ctrl+f5 or only f5) the first .exe which is called by VS is called WebDev.WebServer.EXE which got corrupted may be n number of reasons
--Solution
------ We need to replace this file
------Step 1 ---
go location C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0
You will find this file
-------Step 2 ---
download WebDev.WebServer.rar file from
http://www.2shared.com/file/11532086/a7f9858a/WebDevWebServer.html
-------Step 3 ---
NOTE : You will need password for extraction this downloaded .rar file
Password : optimusprime
------ Step 4 ---
Copy the downloaded WebDev.WebServer.EXE file and replace in this below path
"C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0
"
--------step 5------
run the program
Go to Run >> type >> cmd >> type
taskkill /IM webdev.webserver20.exe
and then try to re run the program
In my case I was using Windows 8 and Windows Firewall was blocking WebDev.WebServer.EXE
So I went to the settings of Windows Firewall > Allow an app through Windows Firewall > Add new
and browse to C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\11.0
Then select WebDev.WebServer to allow.
For some poor souls out there starting using TypeMock on ASP.NET unit tests like me, you need to disable it in Visual Studio to avoid this error: In Tools->Add-in Manager, untick the boxes for TypeMock Isolator. I guess you need to switch this back on for your unit tests.