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.
Related
Relates to Error while using Qt in Visual Studio 2019
I have the same error. Unfortunately I cannot still fix it, as Qt VS Tools for VS 2015 aren't updated. But my question is not how to avoid background build.
My question: what is background build?
Oh, I believe you are running into the 32767 names for this.
Let me preface this by stating that 2015 may have been the last time I used Visual Studio or developed anything for a Microsoft platform.
Part of your answer is in this discussion.
I believe the latest (or more current) name for "background build" is "live code compilation."
This is a resource robbing, highly annoying, syntax checking thing Microsoft thought would be great. It ranks right up there with Microsoft Clippy as far as tragic ideas go.
Basically, as you type, visual studio tries to build your stuff, puts squiggles under errors and generally consumes a whole lot of resources.
If you are using that Qt plug-in to build a QMake project this can cause all kinds of hardship, especially when you have UI files that need to MOC compile and are in the designer modifying the .UI file.
Whatever version of Visual Studio I was forced to use for that project, the first thing I did was find out how to turn that off.
Qt appears to not play well with Visual Studio it seems.
Here is a more complete description if you happen to have the plug-in.
BuildOnSave is an extension for Visual Studio 2019 and 2017 that
builds the current solution as soon a file is saved, and in
combination with the the extension SaveAllTheTime, enables a live,
background build experience while you type.
The title of this question probably seems a bit convoluted so let me explain it in more detail.
I work for a company that has recently requested that all their pre-VS2013 Projects and Solutions be upgraded to VS2013. During my initial upgrade tests I noted that some of the solutions prompted for an Upgrade to be functionally sound under VS2013.
These Solutions/Projects typically launched the Migration Wizard and presented the message that non-functional changes to the Project were required to run under VS2013 and as long as there were no errors present afterward, the Projects compiled and ran without any issue.
While there were other VS2012 Solutions/Projects that displayed no dialogs whatsoever and simply ran under VS2013 without issue.
My initial presumption was since the latter mentioned Projects weren't identified by VS2013 as having any components that required alteration for the upgrade; that they were simply upgraded behind the scenes, compiled without error and simply ran.
But after a short conversation with the Company Supervisor and a peek at the Solution files, it appears that those Solutions are still configured for VS2012 and not VS2013.
Below are a few lines of code from each Solution File:
VS2013 Solution File
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.30110.0
VS2012 Solution File
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
As you can see the VS2012 Solution File indicates # Visual Studio 2012 while the VS2013 Solution File shows # Visual Studio 2013 with an additional line appended to the file stating VisualStudioVersion = 12.0.30110.0
So the real question/concerns here regarding this migration effort are:
Is there any way to FORCE a VS2012 project to VS2013 as opposed to simply opening the project/solution under VS2013
Are there any potential caveats that should be taken into consideration when at some point VS2012 becomes outdated/deprecated by Microsoft? E.g. If tomorrow VS2012 were to become obsolete would there be potential areas of concern for these types of Projects running in a Production Environment?
The targeted goal is to have all our Projects and Solutions migrated to and running under VS2013 for continuity of the environment and simply do away with any Pre-VS2013 items.
Thanks
The ability to open projects created in earlier VS versions without converting them was first added to VS2012. By popular demand, moving to a new VS version could be pretty painful if not all members of a team migrated at the same time.
There is no point about fretting about this, VS2013 just doesn't have any trouble opening and saving projects like this. Nor does it have a way to force the conversion. In the olden days it could be done by running devenv.exe with the /upgrade option. Not sure if that still works, you'd have to try. I've seen SO users recommending editing the project file, I do not think that's a good idea.
It will automatically prompt you for an upgrade when you add any feature that wasn't supported in a previous release. Hard to come up with examples of that for VS2013, beyond Windows Phone 8.0 projects, VS2013 is a relatively minor increment from VS2012.
I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
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.
I'm used to using Idle for Python development, but decided to give Visual Studio 2010 + IronPython a try last week. It seems to work fine, but I noticed that triple-quoted (multi-line) strings don't highlight correctly in the editor. See photo:
Does anyone else have this problem or know of a good fix? Apart from that bug, Visual Studio seems to be great for Python.
This is a bug that is already fixed for the next release - I screwed up storing our state while processing line-by-line when fixing another bug.
If you're really anxious you can actually build the MSI which includes the tools from the sources on CodePlex. Once you have the VS SDK installed it should be as simple as running Scripts\Bat\Dev.bat to setup the enlistment environment and then msbuild Msi\Installer.proj which will produce an MSI in Bin\Debug.