I've got a solution containing a mixture of C# and F# projects (it's a Silverlight app). When I attempt to compile it in Visual Studio 2010 SP1, the build process hangs on one of the F# projects. If I remove that project, it hangs on a different F# project.
The F# compiler (fsc.exe) isn't running, and I can't find any likely-looking process to kill (other than devenv.exe).
It compiles fine on the command line, using MSBuild. It compiles fine in VS11 beta. We can't (yet) migrate the solution to VS11.
This occurs on my PC, and one other PC. None of the other team members have this problem.
Has anyone seen this behaviour before? How do I go about debugging this?
It may be useful to go to Tools\Options\Projects&Solutions\Build&Run and change MSBuild output verbosity to 'diagnostic' and then check the output window to see exactly where things are getting hung, that may help diagnose.
Related
I have a problem with visual studio 2022. I am creating a WPF app in vs 2022 version 17.2.4 using .NET 7 Preview. When I build the solution or press Start Debugging or Start Without Debugging, Visual studio won't update the compiled code(Won't replace binary files with the latest ones) and the behavior of the program won't change to correspond to the code. The problem does not persist when I press Build->Clean Solution and then Build->Build Solution. It does the same whether I build the solution with the debug or release configuration. I tried it with other solutions as well and the problem will not go away. So I know how to deal with this, but it seems weird and annoying nonetheless. It's the first time that I encounter something like this.
P.S.(Yes the solution compiles with no errors or warnings)
we virtualized our build server and having issues building some c++ projects.
It is a win7 (we have some vb6 projects) with visual studio 2017.
When I build a project it just errors out with "This operation may only take place in the UI thread".
Also it is completely random...sometimes it compiles, sometimes it does not.
I have no idea why and what I could try to fix it. I have also a Win10 build machine where the problem does not happen. We want to stick with the Win7 build machine though, because on the Win10 one we got issues with some vb6 projects.
If I use msbuild it works fine, I would rather not replace all devenv calls for now though.
Anyone an idea what the issue could be or how to debug it?
Seems to be an issue with Visual Studio 2017 15.6.x. works fine with 15.5.7
I need some help. I have put in dozens of hours into a VB.NET project, it has been built in release mode and distributed. Now I have to make some changes to it, and I am unable to debug it properly. My code changes result in behavior where my code is not even recognized.
Also, I installed Visual Studio 2013 recently (moving from 2010), but this project behaves the same in both environments.
I believe that my code has become 'optimized'. The error window tells me that code is being skipped over, and that my code is optimized and JIT is checked.
I have turned off JIT, and I have tried everything to make this project work again that I could think of. I am desperately wanting to know how I can get this project to be in a state where it will debug each line of code again when I make changes.
I can even purposely write bad code, and the debugger does not see it.
This project is now in debug mode, not release. I have checked and followed threads on every thing that other people have done to solve this issue, but nothing works for me.
Either my project launches and works properly as it is coded, or if I change any code only the form launches with no code being run - at all.
please help.
I finally figured it out. The applications that I was struggling with were all built in Visual Studio 2010 on Windows 10. I was trying to work with these in Visual Studio 2013 on Windows 7.
Once I tried to work with them on Windows 10 (visual Studio 2013 this time), they started working and debugging just fine.
I think it may have been DLL assembly paths? Took me more than a week, but I figured out my issue by moving from Win7x64 to Win10x64.
I have been trying using Pex in a F# project but I have faced several issues on which I would appreciate some help:
Visual Studio Pex addin worked for half an hour and not for complex project exploration.
After that each time I run a Pex Exploration from within Visual Studio 2010 I get a !warning! [metadata] no explorations found after applying all filters; did you forget a [PexClass] or [PexMethod] attribute? error message. If I copy and paste the command run by visual studio when doing the exploration and remove some attributes (like sourceFilter ...) and run it from a command console then I get some generated tests. Any idea why visual studio generates an invalid command?
After a while the Microsoft.Pex.Framework.dll either disappears from the .Net Reference list and I have to reference it manually using its file path or I can't even reference it any more and I have to uninstall/reinstall Pex. (A reference to C:\Program Files (x86)\Microsoft Moles\PublicAssemblie\Microsoft.Pex.Framework.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.)
All these issues don't occur when I work on a C# project.
Issues 1 2 3 occurred with the Academic version.
Using the version available for MSDN Subscriber I never got it working within visual studio (Visual Studio 2010 Ultimate NO SP1). However it worked from the command prompt. I did not face problem 3 with this version.
Has anyone managed to get Pex working with F# within visual studio ? If yes can you you tell me how you did it ? Which versions (VS and Pex) do you use ?
I have had some success running Pex with F#. The version I used, if I believe my Downloads folder, was the academic version of Microsoft Pex and Moles 0.94.51006.1 Release for (x86). The installation file was named pex.academic.x86.msi.
I don't know if that version predates yours.
My impressions from my trials were that Pex and F# were not a very good combination: Pex insisted on creating test cases with null inputs. As generating null values in F# isn't all that common, that's typically not the scenarios in which I'm interested. Adding lots of assumptions to eliminate those just left me with Pex not being able to generate test cases. Admittedly, the functions I was testing were too complex, I still like the idea behind Pex and might try it again on smaller/easier pieces of code.
Using Pex and its GUI inside VS 2010 worked relatively fine, but not without frustration.
When working in VS, the error messages in the bottom panel are compiler errors and warnings, right? Does this mean the app is being compiled all the time? I would expect those to appear only when trying to run the app.
This is probably a silly question, but I cannot find the answer.
Visual Studio continually parses the source code; this allows it to preemptively report some errors before you actually compile the source.
This is, of course, dependent upon which language you are using. C++ didn't get preemptive error reporting until Visual Studio 2010.
Visual Studio doesn't natively continuously compile code.
However, I just downloaded the 14 day trial of this little app called .Net Demon that's a plugin for Visual Studio. It costs $30, but definitely a nifty tool if you've got large solutions with many projects.
http://www.red-gate.com/products/dotnet-development/dotnet-demon/
I'll probably end up breaking down and buying it, it's pretty slick.
Each programming language is different (each provides a Visual Studio 'language service' specific to that language that provides the feedback), but for the most part, yes, it is being compiled over and over. In F#, for example, the compiler is divided into a few stages, main ones being lexer/parser, typechecker, and code generator, and the lexer/parser/typechecker are running inside VS, and every time you type a character into a file, that file is re-run through those stages of the compiler.
When you compile an application there might be errors and warnings which will be shown at the errors window. When you run the application errors will no longer be shown in Visual Studio but depending on how your application is organized it will either crash or handle them gracefully. Also notice that if you try to run the application with F5 or Ctrl+F5 Visual Studio will try to compile it first and if there are compile-time errors and warnings they will be shown.