I'm working on a Visual Studio extension that should listen for events when the user adds, removes, or renames files in the current solution.
The answer to this question notes that VS provides infrastructure for listening to document events like saving, opening and closing through the DocumentEvents interface. For example:
Dte.Events.DocumentEvents.DocumentSaved
Are there similar events that would allow me to listen to the user adding/removing/renaming documents?
First, don't use DTE if you can help it. It's a very incomplete, shaky abstraction papered over an extremely complex interface. Having said that, I admit that sometimes it's super handy because the equivalent either can't be done without it (rare) or the alternate code would be quite long (less rare).
There are two concepts being conflated here. The first is the Running Document Table (RDT). The RDT represents all the open files (including the open .sln and project files). You can subscribe to RDT events to be notified of files being opened, closed, renamed, etc. But these events are for open files only!
The second concept is the project system. Each project loaded and displayed in the solution explorer is loaded by the project system for that project's type. C++ projects, C# projects, F# projects, WIX installer projects, etc. all have different project systems. There can even be custom project systems implemented by extensions. It sounds like you want to know about events in the project system, and not events for (just) open files. So your focus is the project system. However, since all project systems have different implementations, this becomes very tricky. VS is moving towards a common project system (CPS), but it's not 100% there yet, and even when it is there remains the problem of all the legacy extensions, etc.
You can subscribe to general "hierarchy" events which all project systems must furnish. They'll tell you for example when a file is added or removed (really, when a hierarchy item (node) is added or removed, since there's not necessarily a correspondence between files and hierarchy items). There's also an event that says the entire hierarchy has been invalidated -- a sort of refresh where you have to discard everything you know about the project and gather up new info.
Rename is probably the hardest thing to detect. Every project system implements it differently. In some project systems, a rename will present itself as a node deletion followed by a node addition, with no solid way to identify that it was due to a rename.
To sum up, nothing is as simple as it seems, particularly when it comes to project systems (one of the least extensible parts of Visual Studio). You'll likely end up with code that is specific to one or a handful of project systems, but won't work universally. (After all, not all projects even represent file hierarchies! And those that do still have folders, special reference nodes, etc. that aren't files.)
Some concrete pointers in the right direction:
Implement IVsSolutionEvents3 to be notified of a project being loaded/unloaded (and IVsSolutionEvents4 to be notified of a project itself being renamed). Register that object as a listener in your package initialization code (make sure your package is loaded before a solution is opened) via the SVsSolution service (cast to IVsSolution and call AdviseSolutionEvents on it).
Implement IVsHierarchyEvents to be notified of project changes like node properties changing (use the __VSHPROPID enum to find out which is which), nodes being added, removed, invalidated, etc. Call AdviseHierarchyEvents on the IVsHierarchy object passed to the IVsSolutionEvents3's OnAfterProjectOpen implementation to register the event listener object.
You can subscribe to the EnvDTE.ProjectsEvents, EnvDTE.ProjectItemsEvents or IVsHierarchyEvents.
I know this is an old post by now, but for anyone else, who is searching for a fast solution. Take a look at the IVsTrackProjectDocuments2 class and it's matching IVsTrackProjectDocumentsEvents2 event interface.
You will receive notifications for all project items (Not solution items!), including Solution Items, which match the following actions:
Rename Directories
Rename Files
Add Directories
Add Files
Remove Directories
Remove Files
SccStatusChanged (I am guessing, that it will fire after a file's source-control state changed.)
These will contain an array of the changed items, their new state and the projects in which updates occurred. Additionally you will get a VS*FLAGS array, which contains more information about the current operation.
Related
I'm writing custom language service as described in
https://msdn.microsoft.com/en-us/library/bb166533.aspx
Now I'm writing code for AuthoringScope (https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.package.authoringscope.aspx) My problem is in GetDeclarations method.
I have access to text of current file via ParseRequest.Text property.
It allows me to list all methods and variables in my file but how can I access other files content? I need to get access to other file content for building AST tree of this file but I don't know how can I do this.
Personally I find the MPF "helper" classes (like AuthoringScope) to be a bit restrictive, and implement everything manually (which, I admit, does take more time, but is a lot more flexible in the end).
In any case, it sounds like your language (like most!) has dependencies between files at the semantic parsing level. This means you'll either have to:
a) reparse a lot of text all the time, which is likely too slow in large projects
or b) maintain a global aggregate parse of a project's files, and update it dynamically when the files (or the project's properties) change
b) is obviously a lot harder, but is almost certainly the best way to do it. A general outline would be to discover all projects after a solution is opened via EnvDTE, parse them all (discover all files in each project, again via EnvDTE), and store everything in some sort of indexable data structure so that you can do fast queries against it (for semantic syntax highlighting, go to definition, etc.). Then you need to listen for changes everywhere and reparse appropriately -- you'll need to check for solution open/close (IVsSolutionEvents), projects being added/removed/renamed/unloaded/loaded (IVsSolutionEvents/IVsSolutionEvents4), files being added/removed/renamed (IVsHierarchyEvents), files being edited (IVsTextViewCreationListener + ITextBuffer.Changed), and project configurations changing (IVsUpdateSolutionEvents, IVsHierarchyEvents).
Whether you choose a) or b), you still need to be able to check if a file is opened in the editor (potentially with unsaved changes) or not. You can check if a file is already open in the Running Document Table (but don't forget to normalize the path first using Path.GetFullPath()) via the IVsRunningDocumentTable service, which will return an IntPtr to the document data, which can be coaxed into yielding an ITextBuffer for the file, which contains the text (and entire buffer history!) of the file. Of course, if it's not open you'll have to read it from disk.
Maybe this is the wrong question. I don't understand the hierarchy/relationship between solutions and projects, so I'll describe my goal first. I have a forms application which works. I want to copy everything in it to another folder on the same PC with a different name which reflects the purpose of a new forms app I want to build. I want to use the old parent which I copied as a skeleton, a starting point. I've tried copying the whole WindowsFormsApplication1 and renaming it, but when it builds, it refers to stuff in the old parent folder. I want each of these to be totally self contained, not reference something above the new folder I just made with the skeleton.
Can someone describe the relationship between projects, solutions, the folder which gets created called WindowsFormsApplicationx and the .sln file? If this is too general, I'd be happy with just some step-by-steps to accomplish my goal.
Thanks for your patience,
Lamar
Thanks onlinecop, this helps but I’m still not all the way there.
When I created the forms application, it made a set of files and directories in the Studio2010/Projects directory:
WindowsFormsApplication2.sln
WindowsFormsApplication2.suo
WindowsFormsApplication2 (folder)
Bin (folder)
Obj (folder)
Properties (folder)
Form1.cs
Form1.Designer.cs
Form1.resx
Program.cs
WindowsFormsApplication2.csproj
WindowsFormsApplication2.csproj.user
I used Forms Designer to make a presentation layer, which although it doesn’t change much, it does change some.
I want to start with all of these and may or may not make changes to them but I will want to change all of their names.
Besides changing the names, most of my changes are in the Form1.cs and wherever Forms Designer keeps its changes. Since it is a graphical input and not text, I don’t know where it stores its stuff.
I’d like to do this without disturbing anything with the originals.
Almost none are unit tests, and most are new, addressing different applications so I don’t want to depend on a version control tool.
I’d like to not use them by reference, but instead by copy because I want the parents sequestered and unchanged.
So it would seem that I would want these to have completely different solutions, not projects inside of a solution….is this right?
Will the “Add Existing” do this for me, and where should I do it
As I’m reading the tutorials, my impression is that basically a solution is associated with an application and projects are sub-entities which might be incremental changes to host unit tests or debugging.
So since I want to make a completely different application, which I do not want to have confused with the parent, I’m thinking I want a new solution. But I want to use most of what I had in the parent so how can I create a new solution and populate it with the contents of the old source files and rename them? I’d like to not have them called Forms1.cs and WindowsFormsApplication2…..more something descriptive of what they are, like NeutronMigrationAnalysis…
If I’m asking the wrong question, it might become clearer if I understood when I should create a new solution instead of a single one with a gazillion projects in it.
Thanks!
Lamar
A solution contains multiple projects.
Let's say that you create a Unit Test. That test will run methods that you've created in a different project, just to ensure that those methods work correctly. So within this solution, you actually have two projects: one which is your normal forms app, and one that is a Unit Test which you, as a developer, can see but that end users won't.
The folders are merely hierarchal in nature: It helps you keep your projects separate, and files in places easy for you to find.
So take your original forms project, within your master solution. Your solution file (usually a .sln file) defines that you have a single project within it, and the directory where it's stored. It usually keeps track of other general or global information as well.
The forms project contains its own project file (usually a .csproj file), and is usually found within whatever subdirectory it was initially started in. That will define all the files that you want included, all of the special build options, the logical layout of your folders, files, and resources, and so on.
When you want to recreate a skeleton project, you will usually create a new, empty project. Then, copy all of the source files into it from your form project and "Add existing..." the files so they are seen by this project. Doing it this way will prevent the .csproj file from being copied from the original project and keeping all those old parent folder files/references.
I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.
We have this Biztalk 2009 solution that, amongst other things, writes flat text files (tab separated) to a directory (a Send Port I believe).
Prior to writing the file, some logic is being performed on different fields (stripping unwanted characters, parsing, etc.) and this logic is held in standard C# classes.
Now that I have located this logic, where can I see where it is being used and referenced from?
I'm asking this as I would want to implement the same idea to other fields prior to the file being written.
The solution is quite huge.
I have looked through orchestrations and pipelines and could not find any mention of said classes and its methods.
I also, tried VS's seach "Entire Solution", found some mentions in some XSD/XML files, but nothing that tells me where the previous dev decided this logic would be used. Also tried "Find all references" but being a Biztalk application, it's not doing the same as in a standard .NET solution.
Turns out those classes and their methods are referenced in functoids.
If you open a .BTM file (mapping) you will see how data can be manipulated by these between the source and target schema.
By "Configuring Functoid Script" you can select either Inline C#, JScript.NET and others to perform certain operations on the flow of data between the source and target schema. One of these options is "External Assembly" where you'll be able to select a method from a class that you have referenced in your project.
By "Configuring Functoid Inputs", you'll be able to configure the parameters to be sent to the "External Assembly"'s referenced method.
By searching in "Entire Solution" for the method's name, you eventually find it mentionned in the XML content of the .BTM file. Open the BTM file (by just double clikcing on it in your solution) from there, look for all these "S" symbols in the grid, that's where it'll likely happen.
I am working with a very big project (a solution that contains 16 projects and each project contains about 100 files).
It is written in C++/C# with Visual Studio 2005.
One of the projects has around 2000 resources out of which only 400 are actually used.
How do I remove those unused resources?
I tried to accomplish the task by searching for used ones.
It worked and I was able to build the solution, but it broke at runtime.
I guess because enums are used. (IMPORTANT)
How can I make sure that it doesn't break at runtime?
EDIT:
I think one method could be to generate the resource (that is not found) on the fly at runtime (somehow).
But I have no idea about ... anything.
NOTE: It's okay if a few unnecessary resources are still there.
What I would do is write a custom tool to search your source code.
If you remove a resource ID from a header file (i.e. possibly called resource.h) and then recompile and get no warnings: then that's a good thing.
Here is how I would go about writing the app. Take as input the resource file (resource.h) you want to scrutinize. Open the header file (*.h) and parse all the resource constants (Or at least the onces you are interested in). Store those in a hash table for quick look up later.
For each code file in your project, search the text for instances of each of your resource ID's. When a resource ID is used, increment the value in the hash table otherwise leave it at zero.
At the end, dump all the resource ID's that are zero out a log file or something. Then test that indeed you can remove those specified resource ID's safely. Once you do that, then write another tool that removes the specified resource ID's given the results of your log file.
You could write such a tool in perl and it would execute in about 0.3 seconds: But would take days to debug. :)
Or you could write this in .NET, and it would execute a little slower, but would take you an hour to debug. :)
You can use third party plug-in for Visual Studio as ReSharper. This add-in will analyze your C# code and point out unused resources. But it only works with C#.
For C++ projects, check out The ResOrg from Riverblade.
"The Resource ID Organiser (ResOrg for short) is an Add-in for Visual C++ designed to help overcome one of the most annoying (and unnecessary) chores of developing/maintaining Windows applications - maintaining resource symbol ID values"
http://www.riverblade.co.uk/products/resorg/index.html
I've never had one that bad. My method in compiled programs is to use a REXX script which emulates GREP looking for references to source that I suspect is not being used, remove them from the program and see what breaks. I use the REXX script because I can pre-filter the list of files I want to search. Which allows me to do a search across folders and computers.
If your code contains dynamic loading of resources (e.g. via strings) at runtime, then there is no way to automatically determine which resources can be safely removed from the source. A dynamic loading statement could load any resource.
Your best bet is to start with your trimmed down version of the app, run it, and identify which resources are missing when you test it. Then add them back in and retest.
You may want to take a look at the tool Reflector (free), not to be confused with ReSharper (expensive). It can show you which DLLs are dependent on another. Then if you want you may be able to remove the DLL that is not being referenced by anything else. Watch out if you are using dependency injection or reflection which then could break your code without your knowledge.
Reflector:
http://www.red-gate.com/products/reflector/.
This add-in draws assembly dependency graphs and IL graphs:
http://reflectoraddins.codeplex.com/Wiki/View.aspx?title=Graph.
In the "Resources View" of the Solution Explorer, right-click and select "Resource Symbols". Now you get a list where you can see which resources constants are used in the .RC-file. This help you might be a bit on the way to cleanup your Resource.h (although it does not show you which resources are not used in the actual C++ code).
Maybe Find Unused Resources in a .NET Solution helps here? Basically, you'll have to check which resources are used (e.g. by comprehensive code coverage checks) and remove the unused ones.
And probably you should not be afraid by using the trail-and-error approach to cleaning up.
In the Solution Explorer, right click and on a Reference and click on the menu item Find Dependent Code.
If it can't find any dependent code then you can remove this reference from the project. (The Remove operation is also under the right-click menu.)
EDIT: For a large project, the Find Dependent Code operation will take a long time. So since you have 2000 resources and most likely value your time this probably is not a viable option....
For C++ resources, did you try right-clicking the project in "Resource View" and then deleting the ones which do not have a tick mark next to them? It is unsafe to delete unused dialog resources since they are referenced as "enum"s in code (like the following).
enum { IDD = IDD_ABOUTBOX };
..however for all the others it should be safe.