I'm encountering a problem when trying to create a DSL for use in Visual Studio IDE.
I'm trying to use Visual Studio Modeling SDK to generate a Visual Studio Extension allowing for the drawing of Fault Trees1 and Reliability Block Diagrams2 plus also some Markov Models3 for reliability analysis.
As part of this I'd like two have two 'things', a Gate, and an Event, which both have an output port. As the OutPort would not be shared with other objects, and is really inherent in the object itself, I've tried to make this IsEmbedded.
However the Validation Engine appears to complain when I have this IsEmbedded and 1..1 multiplicity. With a Validation Error that it must be 0..1 multiplicity. Now that I have configured this however, I'm still getting the same Validation Error.
I did post this on the MSDN Visual Studio Forum4, however with no success (I was redirected to Stack Overflow).
Does anyone know of good resources for the Modeling SDK?
Whilst the DSL platform appears to be well suited to do what I'm after, if there is another way of getting the Toolbox drag/drop and node layout capability (easily) within Visual Studio then I'm happy to hear about it.
Related
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.
My company owns several business licenses for Xamarin.Android, and we'd like to use this on our CI server. However, it seems that I'd need to install the full Xamarin suite on my CI server including Visual Studio Pro to make this work. My question is, using the vanilla Xamarin.Android package, how can I activate it?
It seems that installing this on its own adds the Xamarin.Android tools and libraries to build with but there is no way to activate it that I can find, so when I attempt to build using MSBuild, the build fails with this error:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(299,2): error XA9008: Building from the command-line requires aÿBusinessÿLicense.
Now, after some googling, I have found that the activation tool is called "mandroid.exe", which can be found in C:\Program Files (x86)\MSBuild\Xamarin\Android - although I have found references to this being in the 64-bit program files too.
Unfortunately, I can't find any suitable documentation on this tool. Every time I find a thread where someone discusses this, someone from Xamarin jumps in and says "contact support#xamarin.com". After a while I did that but two business days later there still is no response and I've got deadlines to meet so I thought it might be helpful for everyone involved for us to publicly document this process.
The best thing I've found comes from a thread on the Xamarin mailing list which references this invocation:
mandroid.exe --activate --name "NAME" --company "COMPANY" --email "EMAIL" --phone "PHONE" --code "ACTIVATION CODE"
I have also discovered another variant of this invocation that looks like this:
.\mandroid.exe –activate –activation-name="NAME" –activation-phone="PHONE" –activation-company="COMPANY" –activation-code="CODE" –activation-email="EMAIL"
I've tried many permutations of my account data here using both invocations - using the activation code from the products page on the Xamarin store. No matter what though, this error occurs:
\mandroid.exe : monodroid: error XA9997: Incomplete data provided to complete activation
In the "problems activating?" section of the products page, it says this:
In Mono for Android 1.0.21316 and later, if activation within Visual Studio fails then a MfaActivation.dat file will be created within the Documents folder. Select this file below.
Perhaps there's some way to force this file to be created by mandroid.exe? That would be very helpful. While I imagine that offline activation is the only way to make this work, I would accept any answer that involves uploading MfaActivation.dat or otherwise invoking the online activation machinery as well.
Update - I'm afraid that the below steps no longer work. Xamarin has updated their activation system to activate by a different method for newer versions.
In the end I had to install Xamarin Studio as part of the Chef configuration and just instruct administrators to manually activate the software as part of creating a new build node. I had no luck trying to reverse engineer a fix, and if I did, it would probably just break again.
It turns out that I almost had it correct. The second invocation I specified is actually the correct way to call this command but the -- part was apparently converted to a – token by some blog software somehow.
The --activate verb will perform an online activation with Xamarin's servers, so I'm still not sure how you'd do it without an internet connection.
For reference, here is how I did it:
mandroid.exe -v --activate --activation-name "(NAME)" --activation-phone "(PHONE_" --activation-email "(EMAIL)" --activation-company "(COMPANY)" --activation-code "(CODE)"
I'm not sure about the significance of the -v switch, but perhaps that would make it output debugging info if there was a problem.
You must enter all the information exactly as specified on your products page - select one of your licenses and select "problems activating?". However, you will need to enter the licensee name - i.e. the user who owns the license in the --activation-name parameter which must correspond to the --activation-code parameter.
After doing this you can call mandroid with the --activated switch which returns an exit code:
PS> & .\mandroid.exe --activated
PS> $LastExitCode
0
You will also be able to reload the products page and you should see that your license for the chosen user has a new computer registered to it.
This does use up another activation but if you e-mail the support team you can sign the build server agreement and then I assume they can set you up with additional activations for your build nodes.
It's a shame that this wasn't documented better because this has wasted my time for several days. Hopefully this will be helpful to someone else with the same situation.
From Xamarin documentation, we can see
http://docs.xamarin.com/guides/cross-platform/ci/configuring_tfs/
"Visual Studio Professional (or greater) must be installed on the Team
Foundation Server along with licensed copies of Xamarin.Android and
Xamarin.iOS to support development of Android and iOS mobile
applications via the Team Foundation Server."
So I assume that in all cases you need to have VS + Xamarin products installed and activated.
I might be wrong, so the best way is to contact Xamarin support, http://xamarin.com/support
My goal is to create a Visual Studio extension, macro, or addin that would give the user a list of all their variables and parameters. The user would then be able to rename any given variable in that list.
How can I get a list of all variables and method parameters in a Visual Studio project within an addin, macro, or extension? Further, which is more appropriate for this, between an extension, macro, or addin?
You can get most (if not all) information you're looking for through the CodeModel API. This gives a high-level overview. What you'll want to do is get the code model objects for files and projects and loop through to find CodeVariables and CodeParameters. Note this will only get you fields -- local variables aren't expressed through the API. If you also need locals, you might want to try the Roslyn CTPs, with the obvious caveats that it's not done yet.
As far as which technology to build on -- it doesn't have any effect on the actual code you're going to write, since you're going to be using the same APIs no matter how you start. It's mostly a difference of deployment. That said, macros are no longer supported in Visual Studio 2012, and addins can be a huge pain (and are a relatively legacy technology at this point). Do an extension, it'll be the easiest.
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.