Hello I downloaded Z3 from http://z3.codeplex.com/ and then opened the Z3 solution in Visual Studio 2012. (While I'm not totally new to VS I haven't used it in over 10 years). There are 9 projects in this solution but I am having a hard time telling which I ought to be using. I can guess at some of them, but others aren't very clear. Eg. what is the difference between Microsoft.Z3 and Microsoft.Z3V3 ? Can anyone briefly explain what the different projects are and which ones to build?
Anyway just for kicks I tried building the top level solution but got the following errors
Error 1 error RC1015: cannot open include file 'afxres.h'. C:\Projects\z3-src-4.1.2\z3\dll\dll.rc 10 1 dll
Error 2 (same as Error 1 except in shell.rc)
Error 3 error LNK1104: cannot open file 'C:\Projects\z3-src-4.1.2\z3\Debug\z3_dbg.lib' C:\Projects\z3-src-4.1.2\z3\test_capi\LINK test_capi
Trying to build just the MS.Z3 project still gives me Error 1.
My eventual goal is to invoke Z3 from say an F# program. Can someone provide some guidance for how to do this?
Any help would be appreciated.
EDIT
This answer reflects the directory structure used in Z3 version <= 4.1.1. In version 4.3, the code base has been reorganized/simplified.
END EDIT
Which version of Visual Studio are you using? I'm asking because I want to reproduce the behavior you described.
The easiest way to build Z3 is described here.
You should use the Visual Studio Command Prompt, and execute msbuild. It seems you tried that, and got errors. Here is a short description of each project folder:
lib: the Z3 source code is here. This is the important folder. For visual studio users, it generated a static library.
dll: project for wrapping the static library as a Windows DLL. This is irrelevant for users in other platforms.
shell: uses the static library from lib to build z3.exe.
test: a bunch of unit tests. It produces test.exe.
Microsoft.Z3: .Net API. It is the official .Net API (C#, Visual Basic, F#, etc) for Z3. This is the API you should use with F#.
Microsoft.Z3V3: It is the old .NET API. It was the API available in Z3 3.x. We maintain it because some users still use it.
test_capi: Application that tests the Z3 C API.
maxsat: Small application that implements two maxsat algorithms on top of the Z3 API.
Related
I'm trying to build the minimal wxWidgets sample on Windows, using Visual Studio 2019 Commmunity Edition, following the instructions from this page for using wxwidget binaries
I opened the "minimal_vc9.vcxproj" file in Visual Studio. Visual Studio upgrades the project file.
I then added the wxwidgets.props property file to the property manager, and then tried to build ( Build | Build Solution )
It fails with the following error:
1>C:\Users\Administrator\Desktop\wxwidgets\include\wx\msw\chkconf.h(91,1):
fatal error C1189: #error: "wxUSE_UNICODE_MSLU must be defined."
I am trying to help a friend who knows C++ and uses Windows to set this up, but am not sure how to do so. Note both he and I are new to using Visual Studio as well, and I can't find any references on how to fix this by Googling.
Note I am using the project file that came with minimal (no solution file was there), and can see that in it's configuration that it says "Use Unicode Character Set" at `Project | Properties | Character Set"
EDIT: I'm attaching a picture of the IDE/files we downloaded, which I believe are the 3.1.5 version, ie release version as of Dec 4, 2021?
It looks like you're using wxWidgets 3.0, as support for MSLU was removed since v3.1.0 ~8 years ago. Please download 3.1.5 binaries and open minimal.vcxproj project file to build the sample, there is really no reason to use a 10 year old version if you're starting developing with wx.
Also, completely unrelated, but it's considered to be a bad idea to use administrator account for development. wxWidgets certainly doesn't require any special rights.
I
It is very easy to build the library yourself.
Download the source code archive and unpack it in, e.g. c:\wxWidgets
Start msvc, do ^File->Open", navigate to c:\wxWidgets\build\msw and open the file wx_vc15.sln
Select "Build->Batch Build...", click "Select All", then "Build".
When the build is finished successfully, open c:\wxWidgets\samples\minimal\minimal_vc9.sln, let msvc convert it and choose " Build->Build Solution".
Then when everything is ready, create a project as "desktop application", apply the properties file and start coding.
Thank you.
Having just switched to VS2019 I’m exploring whether to use code analysis. In the project properties, “code analysis” tab, there are numerous built-in Microsoft rule sets, and I can see the editor squiggles when my code violates one of these rules. I can customise these rule sets and “save as” to create my own.
I have also seen code analyser NuGet packages such as “Roslynator” and “StyleCop.Analyzers”. What’s the difference between these and the built-in MS rules? Is it really just down to more comprehensive sets of rules/more choice?
If I wanted to stick with the built-in MS rules, are there any limitations? E.g. will they still get run and be reported on during a TFS/Azure DevOps build?
What's the difference between legacy FxCop and FxCop analyzers?
Legacy FxCop runs post-build analysis on a compiled assembly. It runs as a separate executable called FxCopCmd.exe. FxCopCmd.exe loads the compiled assembly, runs code analysis, and then reports the results (or diagnostics).
FxCop analyzers are based on the .NET Compiler Platform ("Roslyn"). You install them as a NuGet package that's referenced by the project or solution. FxCop analyzers run source-code based analysis during compiler execution. FxCop analyzers are hosted within the compiler process, either csc.exe or vbc.exe, and run analysis when the project is built. Analyzer results are reported along with compiler results.
Note
You can also install FxCop analyzers as a Visual Studio extension. In this case, the analyzers execute as you type in the code editor, but they don't execute at build time. If you want to run FxCop analyzers as part of continuous integration (CI), install them as a NuGet package instead.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019
So, the built-in legacy FxCop and NuGet analyzers only run at build time while the extension analyzers can run at the same time the JIT compiler does as you type. Also, you have to specifically say to run legacy code analysis on build, whereas the NuGet analyzers will run on build just because they are installed. And analyzers installed as NuGet or extensions won't run when you go to the menu option "Run Code Analysis".
At least, that's what I get out of that page.
There's a link near the bottom of that page that takes you to what code analysis rules have moved over to the new analyzers, including rules that are now deprecated.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-rule-port-status?view=vs-2019
The different analyzers attempt to cover different coding styles and things Microsoft didn't cover when they built FxCop. With the little research I just did on this, there's a whole rabbit hole to follow, Alice, that would take more time than I have right now to devote to it. And it seems to be filled with lots of arcane knowledge and OCD style code nitpicks that make Wonderland seem normal. But that's just my opinion.
There's lots of personal and professional opinion about various rules in these and basic Microsoft rules, so there's plenty of room to use what you want and disable what you don't. For a beginner, I'd suggest turning on only a few rules at a time. That way you aren't inundated with more warnings and errors than lines of code you might have. Ok, so that might be a bit of an exaggeration, but there's so many rules that really are nitpicks, especially on legacy code, that they aren't really worth it to have enabled, since you likely won't have time to fix it all. You will also want to do basic research and use "common sense" when you decide what to enable. ("Do I really need to worry about variable capitalization coding style consistency on an app that's been ported into 4 different languages over 15+ years and has 10k files?") This is both personal and professional opinion here, so follow it or not.
And don't forget the rules that contradict each other. Those are fun to deal with.......
I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio.
Devenv.exe is required for a MSI package.
I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll
This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.
Where can I find this file?
Are there other ways to build a vdproj without Visual Studio?
Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?
WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.
Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:
An API Set is a strong name for a list of Win32 APIs. The convention
for assigning a strong name to an API Set is to use what appears to be
a dll name. But the purpose of an API Set is to provide architectural
separation between the API Set's name and its associated host DLL
implementation for improved portability of your app, so you should
think of an API Set's name as just a unique character string, and not
as a dll name. For delay load, you use the name of the API Set.
API Sets rely on operating system support in the library loader to
effectively introduce a namespace redirection component into the
library binding process. Subject to various inputs, including the API
Set name and the binding (import) context, the library loader performs
a runtime redirection of the reference to a target host binary that
houses the appropriate implementation of the API Set.
The decoupling between implementation and interface contracts provided
by API Sets offers many engineering advantages, but can also
potentially reduce the number of DLLs loaded in a process.
On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.
Nice article on the technical aspects of this new API-Set feature.
Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).
WiX Quick Start: Here are some of the best links that I have found over time for WiX:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.
Is it technically possible (I don't think this would be restricted), and how do you go about it?
I got my little test app building fine, but when I run it I get a failure dialog.
The debug output is slightly more informative:
The thread 0xe4c has exited with code -1073741515 (0xc0000135).
The program '[3400] OpenCVTest2.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Then I created a Win8 Desktop app, which also built fine but failed to run.
MSVP100D.dll is part of the VC++ 2010 Redistributable which is not compatible with Win8. (Being a hacker I tried it anyway, the installer runs to completion - but the bits aren't installed.)
Is there a compiler flag I can try? Possibly a custom build of OpenCV would fix it, but that would be a last resort, and it might only fix the desktop app.
This guy shows an example of using OpenCV library for performing face detection in a Windows 8 Store app written using C++/CX:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV322
Also, at the below post he also describes how the C++ Runtime works for Windows 8Store apps:
http://blogs.msdn.com/b/vcblog/archive/2012/09/28/10354327.aspx
MSVP100D is not a part of VC10 redist. Note the "D" at the end of its name. That package only includes release builds. Your release builds should work fine. But mixing libraries from different VC versions might get you in trouble. See this. Your best chance is to build from source with VC11.
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.