I'm looking into Visual Studio 2019 Class Designer to draw a diagram including mulitple classes in a package. I've noticed the only export format is Image and the .cd xml format contains absolute paths to the c++ class header files.
I've attempted to manually tweak the paths so they are relative and I now when I open a .cd file I get this:
I did sucessully move a .cd file from one computer to another by replacing the absolute paths prefixes, but it felt like a hacky workaround. I was hoping I can simply use relative paths.
Is there way to tweak the .xml so it's editable again ?
(I've tried undoing the changes, but that didn't solve the problem and I'm suspecting the UUIDs might have something to do with it, maybe?)
What's the recommended way of sharing a Visual Studio C++ class diagram for editing within a team ?
In my experience using relative paths isn't supported and (even absolute paths barely).
The only workaround I could think of is using a script to run wihin Visual Studio to run before openning the diagram on a new machine to detect the source code folder and alter the absolute paths accordingly.
In practice, this would be a nightmare under version control and using a completely separate diagramming tool and manually drawing the diagram is unfortunately the reality of the situation.
(I look forward to an alternative tool that can easily generate a class diagram that can be shared/edited within a team).
Related
Is there anyway within Visual Studio / TFS to identify which project produces which dll?
I'm aware you can look under a particular project's properties and see what the name of the dll is, but in the circumstance where you have loads and loads of projects this doesn't seem very efficient.
I've got the situation where I've got a project that references a dll, which includes a method I want to examine, but I don't know what project produces this dll.
Unfortunately, no. The only way I know is that you may could use a decompile extension. (Strongly not recommend to use) Through the source code after decompile, you can view namespace and judge which project produces the dll. (Under normal circumstances)
And you may also have to face some problems such as:
Legal issues
Need to pay for the extension
Only work for C#/.Net
The source code may be confusion and not standard
This should be a one time activity, you can go ahead and take a look into the project file, in case of C# project the csproj file.
If you do not want to do it opening each file, then i would say write a small tool to read all the project files and look for the name.
BTW, this will be different for different projects, and you need to find out the proper location to look.
I have to figure out what needs to be done to make a very old/shelved/unfinished C# asp.net code base into a working application if it's even possible.
I was pointed to the source where there's just a few things in the root, the important one seems to be this data folder.
It contains a whole bunch of folders mostly titled a, b, c, etc. And those contain files called something like baaaaaa or baaaaaaa.b. I can open some of these up in notepad and see plane old C# source code but it's basically meaningless in this organization.
I've never used SourceSafe, but from googling I guess this is how SourceSafe stored files and their changes or something?
If I have what I've described but no traditional solutions or source is it possible to get the original organized solution with properly name classes and such? Can I even use this? If so, how?
You are looking at a SourceSafe library. You need to:
Get VSS (Visual Source Safe, v6.0d is still available) on your client.
Point it to that root directory as a VSS library.
Then you should see the projects tree and be able to extract everything.
I have some open source components used in different projects. And some times it requires me to take a look at some classes sources from those components.
I do not want to add their sources as a project to my solution to see the source code.
Is there a way to tell Resharper/Visual Studio to open source code from particular location on a hard drive for such a components?
Yes. If you have an assembly reference that also has a PDB with the correct path of the location of the source files, then using ReSharper (and I believe VS too) to navigate (e.g. F12/Go To Definition) would open up the source file in VS. Note that it will have reduced functionality as far as IntelliSense and tooltips go, as it's outside of the current solution and is not analyzed by the VS/R# tools. You will still be able to use F12 to jump to other solutions from that file.
The easiest way to make sure the PDB has the correct path is to build the components yourself, so that a PDB is created with local paths. If the PDB is missing or points at a non-existent path, R# will fall back to displaying class metadata (or the Object Browser, per your settings).
I've got a relatively simple project that is under source control (svn), and I wanted to create an installer. I know that I could (should) use WiX, but as I'm new to creating installers I thought it'd be easier to just use the built-in Visual Studio (2010) Setup and Deployment Wizard.
Unfortunately, it seems that files including external (non-project maintained) documentation, configuration files, and "Content" files are added with absolute paths. This, of course, is suboptimal. I searched the web, but found only the same question, without an answer. Another stackoverflow user seems to have asked a similar question, but the only answer, which suggests ClickOnce, seems off-base (I'd like to have an MSI that I distribute not a web-based installation).
Does anyone know how (or whether) this can be fixed?
With VS2005, sometimes the paths stored in the vdproj file were absolutes, and sometimes relatives. In my case, it seemed to be related to whether the files were accessed via the canonical path or not. Here's a concrete example:
Source is on C:\Views\builddir, open solution C:\Views\builddir\solution.sln and add files from C:\Views\builddir\.. and VS2005 would add relative paths into the vdproj file. However, if you map that builddir to a letter drive, for example, make a subst from C:\Views\builddir to s:, open the solution via S:\solution.sln, and then add files by navigating to S:\.., VS2005 would insert absolute paths into the vdproj files. Whether VS2005 displayed paths as absolutes or relatives had no relation to what it stored in the vdproj files.
So, it may well be that the problem comes down to what path you're using to open that solution.. opening \\server\shareddir\solution.sln might get different behavior than mapping \\server\shareddir to W: and opening w:\solution.sln.
You can always add the files, then use a text editor (e.g. notepad) to change the absolute paths in the vdproj file to relative ones. You'll be fine until you change that project again.
MS doesn't seem to really fix minor bugs like this so much as rewrite the code to introduce an entirely different set of bugs, so VS2010 might still act this way.
FYI, why would one want to map an absolute path to your builddir? It was a holdover from the bad old days when VS didn't do anything correct with relative paths.
As tzerb mentioned, the main source of confusion might be that paths show up as absolute under the property window inside VS, but when you look into the actual VDPROJ file you should see the paths show up as relative. However, as patbob mentioned, I believe the paths ARE stored as absolute when they come from a different letter drive.
It might be easier now but when you start bumping into the limitations of the tool it's going to get real hard. Let's not even talk about the bad practices it will encourage which could end up being real hard for the poor end user installing your product. You've got Visual Studio 2010 so InstallShield LE ( free ) would be a better choice.
Otherwise, to answer your question, it will only use absolute paths if it can't caculate a relative path. ( for example c:\foo\foo.vdproj consuming d:\foo.txt consuming c:\test\foo.txt should automatically be ....\test\foo.txt )
BTW, if you decide to check out WiX and want some "easy" check out my IsWiX project on CodePlex. I'm trying to bridge the feature gap between InstallShield and WiX.
Is there a way to use add-as-link when dragging and dropping source files or entire source trees into a C# project?
Currently, dragging a tree of source files onto a C# project will cause Visual Studio to copy all files to mirror tree below my solution file.
This can be avoided with the the add-as-link option as depicted in the picture below. However, it gets tedious for large trees or when some files in a directory are already part of the project.
Screenshot of the add-as-link functionality in Visual Studio http://jaapsuter.com/images/add_cs_file.jpg
I've looked in Tools->Options, searched the web, and held various magic key combinations when dragging and dropping, to no avail.
I'm tempted to write a script that just globs my .cs files and runs a regular expression over my .csproj file. I'm aware of NAnt, Premake, and other solutions - but I'd like something lightweight.
Although this question has been answered, I thought I'd provide another way, because I found this question while figuring out if it was possible to add linked files in Visual Studio using drag-drop, rather than the cumbersome Add Items dialog box. And while the answer here wasn't what I was looking for, I found out myself:
Holding down CTRL+SHIFT down while drag-dropping, will create linked files. Additionally holding down only CTRL will create copies, but not remove the source file.
What you can also do if you don't find a solution is bind a directory to your project by hand once and let the project find all .cs files in that directory automatically when it loads.
This is easily done by changing your MSBuild file in the following way:
<ItemGroup>
<Compile Include="SomeDirectory\**\*.cs"/>
</ItemGroup>
This will take all .cs files in SomeDirectory and include them to the project. This is very useful if there are often a lot of files added to the project. However, it may break on some machine adding useless files. That's why I would only recommend that on an external project that's not editable in your current workspace.
Probably not what you're asking for, but once I had two .NET applications which I wanted to share a lot of source files and so I placed both Visual Studio solutions in the same directory! It actually works, although I guess that a lot can be said about this approach...
Otherwise the most beautiful way to share code is by placing the shared code in a separate assembly, although this requires quite a bit of extra work if it is not written like that in the first place.