I'm having an issue in Visual Studio 2012 that don't allow me to set breakpoints in my code and debug it.
As you can it in the image, the compiler is telling me that I don't have symbols loaded and, taking a look at "Modules" in the Debug tab, I can see that there are some of my dll's symbols that where not located properly and I don't know why because I installed all by using nuget.
I did all the suggestions made on this post (clean and rebuild, I set the debug info as 'full', I disable 'Just My Code' checkbox, I deleted the ASP.NET temporary files, etc) but I could not hit this breakpoint at the moment. It seems that is not finding the .pdb files correctly, where I can find those?
Have experienced exactly the same in VS2013, and I just hit it again.
I had other REST API entry points in the same projects, which were still working, so in the end - last time - I renamed the API/controller, created a new API and shifted the logic over there, which in the end seemed to work. Only a workaround, but at least something if you're stuck.
This second time around I tookkind of a nuke approach: started quitting/restarting VS, excluded the class with the REST API, did a clean + rebuild on the project + solution, included the class again, plus clean and rebuild. ... perhaps some VS-restart again. Ultimately it got synced and I was able to load and debug the api.
far from ideal, but in case you just want to force past it I guess.
You could also upgrade and try the VS2015 (free version) - subject to the size / fetaures of your project - and see if it handles the issue better. (I've installed it next to my VS2013 pro).
Related
I made a new .NET Class Library solution if TFS, and added a bunch of preexisting classes that were developed for a windows forms application. Basically just dumped the old folder in. The forms app worked fine and the folders in bin were expectedly barren, apart from the exe and the required nuget references. The dll build however copies over libraries all the way from Microsoft.Win32.Primitives.dll, to System.Xml.XPath.XDocument.dll for no apparent reason. I have removed unused references with ReSharper and commented out unnecessary using statements. No difference whatsoever. I don't think it's a problem from the deployment perspective, it's just annoying to have so many files copied over each build. Could it be that the initial presence of Forms just poisoned the new project forever? Any help whatsoever would be much appreciated.
Prevent Visual studio 2017 from copying almost 100 unnecessary system
dlls to output folder for dll project
Please check if your VS2017 is very old and also check if the framework version of your project targets to 4.6 or 4.7.1.
If so, there is an known issue about this issue.
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2. You can check this similar issue.
Suggestion
1) you should first update your VS2017 in case some updates fix it.
2) change the framework version of your project to net framework 4.7.2.(if you do not have net frameowork 4.7.2, you should install it in the VS Installer)
Xamarin Android project is built well locally on Windows/Mac, but fails on AppCenter/Azure pipelines with weird errors like:
Error APT0000: resource style/Theme.AppCompat.Light.DarkActionBar (aka com.companyname.build_testing_andx:style/Theme.AppCompat.Light.DarkActionBar) not found.
Error APT0000: style attribute 'attr/colorPrimary (aka com.companyname.build_testing_andx:attr/colorPrimary)' not found.
This mostly looks like lack of necessary libraries to restore by Nuget.
As it appeared after long investigation, and no matter how the solution sounds dumb, but the solution might save some time for someone.
The reason such projects can't be build on AppCenter/Azure (and that might be related to any other Visual Studio project) is that Nuget packages not being restored successfully.
The problem is that when using Nuget task, it doesn't indicate any issues. It just finishes well.
But it happens because the sources don't include *.sln file, thus Nuget doesn't have a point where to start from for the packages restoring.
Sometimes it might happen when this file is just not included into sources pushed to repository by number of reasons.
*(It's weird because the builds often project-oriented, and when working on Visual Studio it automatically creates the .sln file (not necessary around the project folder), so sometimes it might just be not included and you have no idea what's causing the errors above).
So, just to be sure you've got your *.sln file added to your repository and it's available for the AppCenter/Azure build.
I'm working on an ASP.NET application in Visual Studio 2017, and I'm noticing a "Node.js: Server-side JavaScript" process running at 1.3 GB to 1.8 GB of memory. My IIS worker process is the normal size it is in Visual Studio 2015.
My application doesn't include any Node.js libraries. I'm not able to figure out how to turn this Node.js: Server-side JavaScript process off. It's eating up too much memory for something I have no use for.
Is there a way to kill this apart from uninstalling Visual Studio 2017 and switching back to Visual Studio 2015?
Killing the main process in Task Manager doesn't affect anything in Visual Studio. However, if I go to the Details tab and kill the individual running processes, it crashes Visual Studio. I took a video of what happened after I killed the process and ran my local web page (sorry for the quality; Stack Overflow limited image size to 2 MB):
In menu Tools → Options → Text Editor → JavaScript/TypeScript → Language Service...:
Uncheck 'Enable the new JavaScript language service'.
Restart Visual Studio
This appears to prevent the Node.js process from starting.
I raised feedback on this issue:
Visual Studio 2017 - Node.js Server Process - Turn off?
I got a response back from the Microsoft team - he directed me to this post:
Node.js server-side JavaScript process consuming too much memory
The node.exe process has the command line:
Effectively I was told:
In Visual Studio 2017, several features are implemented in JavaScript. Node.js is used by Visual Studio to run that JavaScript. Among other things, Node is used to run the code that provides formatting and IntelliSense services when a user is editing TypeScript or JavaScript. This is a change from Visual Studio 2015.
You have to disable TypeScript support in Visual Studio:
Menu Tools → Extensions and Updates → TypeScript for Microsoft Visual Studio → Disable.
After that, just restart Visual Studio, and you are good to go.
Ryan Ternier's answer pointed me in what I believe is the right direction. Following his link led me to Bowden Kelly's answer, right beneath the accepted answer.
Here is Bowden Kelly's answer:
The node process you are seeing is powering the JavaScript language service. You will see this process appear anytime you edit a JS file, TS file, or any file with JS/TS inside (html, cshtml, etc). This process is what powers IntelliSense, code navigation, formatting, and other editing features and it does this by analyzing the entire context of your project. If you have a lot of .js files in your project, this can get large, but more than likely the issue is that you have a lot of library files that are being analyzed. By default, we will scan every .js/.ts file in your project. But you can override this behavior and tune the language service to only focus on your code. To do this create a tsconfig.json in your project root with the following settings:
{
"compilerOptions": {
"allowJs": true,
"noEmit": true
},
"exclude": [
"wwwroot/lib" //ignore everything in the lib folder (bootstrap, jquery, etc)
// add any other folders with library code here
],
"typeAcquisition": {
"enable": true,
"include": [
"bootstrap",
"jquery" //list libraries you are using here
]
}
}
Once I added the folder with all my script libraries into the tsconfig.json file, life was good again.
The dirtiest workaround ever: just rename the ServiceHub.Host.Node.x86.exe to something else. It hasn't bothered me since. When (if) you actually need it, just rename it back.
The same trick works in Adobe Photoshop which also runs Node.js for some reason I haven't discovered in my usual workflow yet.
It turns out...
You can't just rename it and expect things to keep working. Who knew!
Apparently this renaming trick only works if you suspend the Visual Studio process, kill Node.js, and then resume Visual Studio. If you try to launch Visual Studio with the Node.js EXE file renamed, it will crash when opening a project with an "unknown hard error".
Also, while working on an already loaded project, the lazy reference counter above methods and properties won't work because apparently that relies on Node.js being there somehow.
So it might be okay to just suspend the Node.js process and let Windows paging swap its memory out from RAM onto the hard drive, without renaming the EXE file, so you could start Visual Studio again later without going through the renaming hassle. If you're willing to live with the consequences, that is.
Something that can help the projects mitigate the Node.js weight is to reassign the node version used under menu Tools → Options → Projects and Solutions → Web Package Management to an installed 64-bit version. Visual Studio will still launch its internal Node.js process for a tsserver.js instance, but any TypeScript code in the project will default to the supplied version -- and this helped me firsthand.
Also, another time I found the language service to be running down, I discovered using a simple tsconfig.json file above the directories used as repositories, and specify to skipLibCheck: true, and add node_modules to exclude—it tremendously helped along the service, and one file does all folders beneath it, regardless of direct project references. P.S.—if you do want JavaScript intellisense support still, make sure to set the allowJs: true and noEmit: true option.
Lastly, verify in the TypeScript Options under the menu Tools → Options → Text Editor → JavaScript/Typescript → Project that it is not checked to Automatically compile TypeScript files which are not part of a project since that can also tie up resources for auxiliary third-party projects using Node.js or TypeScript.
These are not foolproof. Each has to find their exact bottleneck, but I have found these have worked for me and my team more often than not.
I am just noting that the high-memory consumption has been fixed in the 2017-05-10 version of Visual Studio 2017 (version 15.2, 26430.04) release.
Release notes are at Visual Studio 2017 version 15.9 Release Notes.
Specific notes about the fix are at
Node.js server-side JavaScript process consuming too much memory.
In my case I did not want to kill the Node.js process, and I did the following things to lower the CPU consumption of Node.Js processes that run under Visual Studio 2019:
I removed folder "Program Files (x86)/MicrosoftSDK/TypeScript
I run npm rebuild fsevents
I turned this off in Chrome browser: Settings-System-Continue running background apps ...
It now seems much better to me. But not 100% unfortunately.
To disable Language Services in Visual Studio Code, go to extensions, then filter on built-in extensions and disable the TypeScript/JavaScript language service.
I finally discovered this after Visual Studio Code's Node.js service crashed my server about a million times. It was annoying that this was so hard to find documentation about.
When I build my solution with a bunch of cloud projects, I see one or more "Error: Object reference not set to an instance of an object" messages in the output. When I try to run one of the cloud projects, I get the popup "There were build errors. Do you want to continue and run the last successful build", but there are no errors in the Error List and the same "Error: Object ref..." errors in the output.
When I click package on my cloud project I get a messagebox with "Object reference not set to an instance of an object", also when I right click -> properties on the project reference under "Roles" in the cloud project.
If I use the command line to build my solution with msbuild, I don't get the error.
I tried restarting Visual Studio as well as my PC. I also tried reinstalling Azure Tools (2.1) and then Visual Studio.
My colleague is now getting the same problem on Visual Studio 2013 RC.
Has anyone had the same problem?
I've searched, but only found people with problems when publishing, where the solution is to package manually.
I had the same problem. Right click on the cloud service project, unload the project. Reload it again.
Try removing the role from the cloud project, re-build solution (if there are errors please post them), then add the role back into the cloud project and re-build.
I had a similar issue when a publish exited out and I started receiving the 'Object not found' error. VS2013 (in my case) was reporting that 'diagnostics.wadcfg' was missing and had unusually stored this into a different directory.
By going into the project file (.ccproj) and removing the erroneous entry from the 'Project\ItemGroup\Content Include "\diagnostics.wadcfg" and reloading the project - everything kicked back into life.
Failing that, check a working project file against the offending project file for inconsistencies.
You don't have to remove your roles and add them back in again, which is really annoying because you have to preserve the contents of your cscfg and csdef files. Instead, close Visual Studio, delete the solution's .suo file and open the solution back up again.
I wanted to let everyone know I was dealing with a very similar situation, albeit with a different version of the Azure SDK (1.8). I have many projects with Cloud Services that I have created built numerous times and then all of sudden could no longer open them. Attempting to open the Cloud Service configuration UI resulted in the “Object not set to a reference” error. I could open the actual XML file, but not the GUI interface.
I attempted to reinstall the 1.8 SDK and tools numerous times, as well as VS 2012 to no avail. I finally tried installing the latest SDK (2.2) and now I can open the projects. Not sure what changed in my system prior to this but glad I was finally able to open my projects again!
I also had this error when building. Projects within the solution would build independently but building the entire solution failed.
I have learnt usually these types of issues are caused by invalid azure role or configuration files. In my case it turns out a .cscfg config file rename on another branch was merged with my branch but it didn't rename the file – therefore the .ccproj file in my branch was incorrectly referring to the new name but only the old filename existing in the solution. After manually editing the .ccproj with the new filename I closed/reopened the solution and things started working.
I had a similar issue with VS2013 express after creating a view in my MVC project.
I reverted the project with git, but this did not solve the issue. I also checked the project out to a different location on my pc, but this did not solve the issue. I was able to check the project out on my laptop without seeing this issue.
In the end, I undinstalled VS2013 express and all of it's counterparts and re-installed. This solved the issue.
I had this bug (but not using a cloud project). Turns out the character encoding that Perforce (P4V) was using was wrong, it should have been UTF-8. After changing to UTF-8 and re-syncing the code, Visual Studio was able to find and compile the project just fine.
Maybe a hint: I got the same error message, when compiling VS2013 Dot42 project - realized it was caused by assigning concrete value of some inner type (in my case Enum) to INullable variable:
private SomeClass.SomeEnum? _var1;
...
_var1 = SomeClass.SomeEnum.XY; // causes compilation error
The solution was, not to use INullable:
private SomeClass.SomeEnum _var1;
None of these answer helped me. I decided to reinstall the Azure tools, and noticed that I had more than one version installed. I uninstalled the old versions, reinstalled the latest version, and this fixed it for me.
I got the same message while publishing our project too, though in Visual Studio 2010.
For me, deleting all the files from bin folder worked.
Unfortunately this is going to be a pretty open-ended question, but I am at my wit's ends and I thought I would reach out for some advice.
This is a Visual C++ MFC app using Visual Studio 2008 SP1.
A coworker and I both had Office 2007 installed and we have both had strange DLL loading problems with our app since. Specifically, LoadLibrary is failing to load one our DLLs ( the first one it loads ) and returning error code 126 ( module not found ). What's really strange is that if I just run the executable from the windows explorer it works fine.
I took the usual steps to diagnose the problems:
Verify that the file existed and that the current working directory was pointed at it.
Run dependency walker and verify that it's dependencies are loading correctly. They are all loading ok except the ones this question says are ok to fail.
Experiment with loading some different DLLs at the same location in the code. Some of the simple 'stub' dlls succeed, but most of them fail.
Experiment with loading the DLLs that are failing from separate test apps - in an empty console app and a barebone MFC app, all the DLLs are loading fine!
Try to load the DLLs with LoadLibraryEx and the LOAD_LIBRARY_AS_DATAFILE flag, which does succeed but doesn't get us very far except to point out it's probably a dependency problem.
I really don't know what else to do at this point. Like I said, Office 2007 is a common thread in our problem but I don't know what kind of problems it could create. I really don't know even what steps to take next. Any ideas?
edit: I'm pretty sure the current working directory is not in the DLL path for some reason. It seems the DLLs that are failing are ones that need any other DLLs. If I turn on Loader Snaps debug output the current working directory does not appear to be in the DLL loading path. Any idea what could cause this?
edit2: The current build dumped the executable into a directory other than the working directory. For some reason, when I tried to load a DLL which then tried to load ANOTHER DLL, the current working directory is no longer searched. By putting the executable into the directory with all of the DLLs I am trying to load, the problems go away. Based on all of this, and the output by loader snaps, I am 98% sure this is some bizarre Visual Studio bug and I will simply have to work around it.
Office 2007 turns on SafeDllSearchMode in the registry.
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
With SafeDlLSearchMode, the current directory is no longer searched. To disable it, they claim you can go into regedit and set HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode to 0, but this did not work for me. Calling SetDllDirectory to the current directory DID work for me, although this only works if you are targeting XP SP1+.
The reason this caused problems in my specific app is that when we run the executable from the debugger, we keep the executable in a different directory than the current directory with all the other build files. When we run outside of Visual Studio, we first copy the executable into the directory with all of the other DLLs. The directory that the original executable is called from is ALWAYS in the search path, so if you keep your executable and your dlls together, you would never run into this problem.
Still, it's quite confusing for Microsoft to change the dll search path under us like this.
Does the DLL which fails has MSVCRT80 in dependencies? If yes, the most likely reason is that Office 2007 has overridden MSVCR80.dll