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.
Related
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.
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.
I am in the process of learning ASP.NET Core MVC, while experimenting, I noticed that when I try to refactor the code using the built in refactoring tools provided by Visual Studio they don't work very well. For example:
Renaming a class via the solution explorer pane usually fails. When it succeeds it will fail to rename the class on the view declaration (eg: #model ClassNameIsNotRenamed);
If I rename a controller or action, the helper tags such as asp-controller="NotRenamed" and asp-action="NotRenamed" do not get updated.
etc.
I don't want to get too detailed on what works and what does not work, the point that I am trying to make is that VS 2017 does not appear to do a good job when it comes to refactoring.
So my question is... Am I asking to much from VS 2017? Is there something that I can do to make refactoring work better?
Thanks.
Doing something like a rename requires that your project can build successfully. If you attempt rename something like a class, and the project either hasn't been built or failed the build, the rename will fail as well. This is fairly logical, as doing a rename refactor requires tracking references, which it can't do without the IL.
As far as your Razor views and controller/action references go, you're dealing with strings and/or code that is not compiled. As a result, it doesn't participate in code-based refactoring generally. Certain things like renames give you option to search strings as well, which you can do to catch more places where things should be renamed, such as your controller/action references. However, that can also cause unwanted side effects if you happen to be using the same string somewhere else, in a different context (which is why string replacement is not done by default).
I've got a WSDL service definition checked into our repository. I've noticed that it has changed between versions, and I would like to see what exactly has been changed.
Unfortunately, said WSDL file is a singe-line XML file, albeit a pretty long one. TFS compare shows the entire line as changed, which isn't really helpful.
How can I compare changes between versions for a long single-line XML file in TFS?
PS. Obviously I could copy both versions, format them, and use an external comparing tool. What I'd like to know if there's a way to do this comparison using tools provided by VS / TFS.
You don't need an external tool as Visual Studio can compare any file, even local files located on the local file system:
But you still need to do some formatting (a basic search ">" and replace ">\n" would do though) in order to locate the lines which have changed.
TFS will only do line for line comparison, so single string to single string. You are going to have to use an external tool if you want more information about what was changed.
I would suggest prettifying/formatting the XML and then doing the comparison on both versions, it should be fairly simple to spot then.
I will be upfront I represent the company at hand, but I'm fairly certain this can help you.
This use case is exactly what DeltaXML is for so please feel free to take a look at our free evaluation or free online sandbox to provide you with a line by line comparison or your XML.
http://www.deltaxml.com/products/core/
Our application requires quite a few tools and utilities we have written to support our product. Things like data converters, backup utilities etc. Currently, each of these utilities is a separate Delphi Project. On top of that, many of these projects also have a corresponding DUnit project for unit testing, which also have to be a separate project. We currently have 13 separate Delphi projects. These projects are all in one Project Group.
Is this necessary? Do we have to have so many separate projects, or is there a way in Delphi to have multiple entry points into the same project?
Also, sometimes it would be convenient during development to just write some code and 'run' it. To do this now I end up hacking the project file; commenting out the normal behaviour and replacing it with the code I want to run. Is this the only way?
We use Delphi 2010 if that makes a difference.
You can do either of these pretty easily:
Combine your projects into a project group, to be able to work with them together more easily.
(My preference) Separate your projects into different units (instead of project files), create a single application that uses all those units, and call different functionality based on command-line parameters (see ParamCount and ParamStr in the documentation) You can then easily write unit tests by testing each of the units (pun not intended) separately.
Regarding your edit: Delphi is a compiled, not interpreted, language. You can't just "run" code without compiling it, unless you can use functionality that's in your app using the Evaluate/Modify menu item during debugging. (Set a breakpoint and run your app. When it hits the breakpoint, use Ctrl+F7 to open the Evaluate/Modify dialog. Note that this has limited functionality due to the nature of the optimizer and compiler.
Organize your project in one or more Project Groups, and you could use project (exe) parameters to execute just some part of your exe.
As it was already mentioned you can convert mini projects into units. Then use compile conditionals ($ifdef etc.) to select which unit is being included in the compiled program. It would be also handy to be able to automatically switch the name of the generated executable file. I think it would be possible to create a relatively simple OTA (Open Tools API) plugin that could control all those features.
To run small parts of code you can create a separate lightweight console project where you can paste the code to the main function.