VS2008 SP1, Winforms solution, VB.NET, compiling for x86 and .NET v2
I have about a dozen projects in the solution, with a couple of Windows forms projects and some class libraries.
If I rebuild the solution, it clears out and recompiles all the projects, as you'd expect...
... and then disappears without trace or error message. Since I'm reconnecting to VSS 2005 over HTTP across the internet, it takes all month to start back up with everything loaded, so it's incredibly irritating.
The compiled application itself works fine, and normal build and run after changes also works fine.
Any ideas why this might be? I've Googled without much success.
Thanks in advance.
EDIT: Just to clarify, No add-ins except Refactor! (I know, I guess I ought to try uninstalling it to see if it's that, but it's just too useful! - I will see if there's an update though).
And no custom build steps. It's just a vanilla Winforms app, with references between the projects (and some references to COM dlls for interop).
Thanks for the ideas so far..
EDIT AFTER PROBLEM SOLVED
Ok, guys, thanks again for all the ideas.
It turned out to be the version of Refactor! I was using. I installed the latest, and the crashing stopped... and Refactor! stopped working too. So I shut down VS, uninstalled Refactor! completely, and reinstalled the latest version... and now I no longer get the mysterious crashes, and Refactor! works again.
You might say, 'Duh, why didn't you try this ages ago', and it's a fair question... you know the way it is - something that happens intermittently... immediate pressures of urgent priorities... and of course the new version wasn't available then, and the benefits of the old version weren't trivial.
So, 3rd party addin the culprit.
Thanks again..
Do you use any third-party plug-ins, it will cause this too.
I had this issue with a couple of WinForms apps. I had to perform these exact steps in this exact order.
Close all of the designer files from the IDE. Or just close all of the files so your workspace is empty
Exit all instance of Visual Studio
Open VS, open project, do a full rebuild. That fixed me ... for awhile.
The common denominator for me is that all project that this happened to were created using older versions of Visual Studio. That's as far as I got tracking down the problem though.
I had no 3rd party plugins installed at the time.
Hope this little bit helps.
Try to debug Visual Studio, using WinDBG or Visual Studio. Attach to the faulting Visual Studio (before it crashes) and make sure that you stop on all exceptions.
If its a managed exception then you can probably understand what happened, if it's not try to see in the callstack who is the faulting dll.
Also try to work without source control, the quickest way is to disable the network card (no kidding).
reinstall Visual Studio...
Do you have any custom build steps for any of the projects you're building? They could be causing the crash.
You're forgetting VSS as a plugin.
I recommend you to change your source code control system to SVN. It will cost you a couple of days or may be weeks to get used to it but it worth the pain.
I know that's not always in your desition scope but if it is you will have lots of benefits with that change.
Related
So I right click on the solution > add > new project > find azure function > choose template > create that
And then nothing happens. If I swap to folder view, I see a new folder made for the function, but its an empty folder.
Weirdest thing is, this was working perfectly fine and a moment later, it became how it is right now. I've not updated vs in between, I've not restarted in between. It was literally closed vs, opened again, and then vs broke.
Older solutions that has functions in them, tried creating a new one, doesn't work same story. Made new solutions and start it off with creating a function, didn't work as well. Reinstalled vs, also did not help, still the same issue. Any ideas how I broke vs?
Also, this works from powershell, I can create functions from there and then go back to vs to add an existing project. However the functions I've build using this method had runtime errors (I think) when I publish them into azure. Regardless, I really would like to be able to create functions normally in vs.
As we can see from the comment section of the question, the solution was:
Go into Tools -> Get Tools and Features
download the .Net desktop development
As Maybemonday described in his/her comment, functions can be created afterwards.
You can solve the issues by installing the right tools.
When setting up the VS 2022 -OR- by navigating to Tools -> Get Tools and Features, install the following workloads:
.Net Desktop Development
Azure development
You can also observe the icon changes from a "Project" type to "Azure Function App" type.
I'm not sure why, but once I renamed C:\Program Files (x86)\dotnet to C:\Program Files (x86)\dotnet.delete, it started working. I think the x86 dotnet binary was earlier in the path and was causing issues.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)
Recently Edit and Continue with VB.net has been kinda flaky.
In one project in particular. It was working as expected the last time I touched this project.
Recently when I pause the project while the winform message pump is running, I get a message saying no code is running. When I go back to my class file (in the same project, not external) I cannot make any changes - typing does nothing in the editor.
I have another class which is part of this solution, it has no entry point but I thought I would remind VS which was the startup project. This made edit and continue seem to work. I could make changes in the code, but when I continued the old version of the code was what was actually running. It's as if I am in an external class.
I just noticed something else, when you first start the project, edit and continue seems to work fine. After you continue, if you break the code again, it stops working.
I never had edit and continue problems at all with VS2012.
VS was hanging and crashing a lot yesterday so I rebooted my computer. That did not help this problem. I also installed SP1 and that did not fix anything.
I tried compiling to X86 and Any CPU.
Is there a setting I am missing? How can I get this working?
Thanks,
Brad
I tried a few more things based on some suggestion in other forums.
I repaired VS, I reinstalled VS, I tried to restore my default settings. None worked. I tried a simple project to duplicate the issue that I could share to get feedback. I could not get it to not work.
So assuming then the problem was with my project and not VS I made a new project and brought over my forms, modules and classes from project with the problem. I added my references and... edit and continue now works! The only things I changed from the default project were: Target CPU: x86, and Target Framework: .Net Framework 4
I still do not know if there was some corruption or it was a bad setting. This project was originally ported from VB6 many years ago and has been through a few VS upgrades as well.
I have an Excel VSTO AddIn that I moved up to Excel 2007/VS2010 last fall. I tried using ClickOnce but the headaches involved with that were just insurmountable and every install became a manual one. I moved to to a MSI setup, but now that is starting cause problems when upgrading. I have a machine now that will not install it properly, and when I try to run the VSTOInstaller.exe manually, I get the following error. I have cleaned EVERYTHING off the system and tried multiple times to get this to work, but no dice. Normally it creates a whole bunch of garbage files in the "Users\Apps\Local..." area, but not I get nothing. I have tried rebuilding with various configurations, all of which result in the same error:
System.Runtime.InteropServices.COMException (0x800736B3): The referenced assembly is not installed on your system. (Exception from HRESULT: 0x800736B3)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Basically, I hate ClickOnce and I'm totally frustrated right now. How do I create a "normal" setup app for VSTO?
Thanks!
Tip 1:
You might have to install:
Microsoft Office 2010 Primary Interop Assemblies Bootstrapper Package"
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=5d57c998-b630-4f38-afaa-b79747a3da06&displaylang=en
(Probably your machine has only the 2007 version of the bootstrapper currently.)
Tip 2:
Run program "mage.exe" with the -cc (ClearApplicationCache) option
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
Good luck.
I was finally able to track it down to the ClickOnce cache, which I was very disappointed about because I was hoping that the MSI would have no ClickOnce to deal with. Once that was cleared by manually deleting the folders, I was finally able to get it to install. But ClickOnce is a simply awful install application.
Not a lot to go on here, but are you sure you've got the right .net runtime installed? With 2010, you may have targeted the client or compact framework, or maybe .net 4.0, but the target machine had an older .net on it. There is also a way to log all the DLLs that an exe depends on as the EXE is requesting them, during the load process, but for the life of me, I can't recall what that process is called so I can't post any links to that right off.
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!