Accessing properties of a project using EnvDTE - c#

I'm writing a visual studio add-in to automate some of our BizTalk related tasks.
I'd like to be able to access the property values of a project (not what shows in the default 'Properties' pane. The properties shown in a window if you right click on the project and select 'properties' from the context menu.)
Specifically I'd like to get/set the application it deploys to, assembly signing, etc. The rest of the add-in is already working.
Thanks!

I'm not sure it includes deploys/assembly signing and it's hard to give a complete sample as there is lots of supporting code, but you can start from IVsSolutionBuildManager.FindActiveProjectCfg, cast the result to IVsProjectCfg2 and enumerate OutputGroups.

Related

Item Templates Sometimes Missing in Visual Studio 2017

Using Visual Studio 2017, sometimes new item templates are missing, and it seems to be tied to the particular project to which I'm trying to add an item.
Although both show up as "C#" projects...
...in "Logging", for WPF items, I have only UserControl (WPF) as an option:
However, in "SanityCheck", I have a much-more-full list of WPF options:
The only difference I can easily see so far is that the one ("Logging") is a Class Library project while the other ("SanityCheck") is a Windows Application project. However, changing Logging to Windows Application doesn't make more options available, and I ought to be able to create a Window in a Class Library, right?
I also noticed that Logging didn't contain all the same references as SanityCheck, so I added all the ones that seemed possibly-related, and that also didn't make any difference in the set of templates available.
So how do I get my Logging project to let me add a WPF Window?
Thanks to a comment from ASh and the list referred to from this question, I determined that the cause was a missing <ProjectTypeGuids> block in the Logging.csproj file. I copied the one from the SanityCheck.csproj file and now all the C# WPF templates are available. So far I haven't encountered any negative side-effects to this solution. Time will tell.

Go to source in a multi solution enviroment in Visual Studio 2019

We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. its 10 dlls) to a shared single folder like C:\code/assemblies.
If I develop something for feature X, I'll open up SolutionX.
The source for all solutions/projects is local in a single Monorepo C:\code.
During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.
But when developing, I cannot navigate to the implementation e.g. by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.
So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".
Any better ideas?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.
I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
In the Debugging information list, choose Full, Pdb-only, or Portable.
Refer for more information:
Set debug and release configurations in Visual Studio
Publish symbols for debugging
B. Use Symbol in Visual Studio:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
Under Symbol file (.pdb) locations,
To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.
To add a new symbol server location,
Select the + symbol in the toolbar.
Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format.
Tools - Options - Debugging - Symbols page
For more Details refer:
Configure symbol locations and loading options
I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions
Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
Navigate to the source and then edit them in place
To achieve option (1)
In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.
On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.
If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs
To Achieve option (2) :
You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. (https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/). If you are referencing source, you need to remove the binary references.
And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.
Conclusion
From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.

WPF Project with Custom XAML Controls

I am new to WPF coding. I have a project that has custom controls coded as xaml's with C# code-behinds. I try to import these files into another project and when I try to use these xaml controls in my main view file, Visual Studio cannot find the namespace that the imported xaml's and C# code-behinds are attached to.
I tried changing the namespace to be the same as my current project. I tried restarting Visual Studio 2013. Neither of these worked.
I tried adding the project with the custom controls to my solution. The imported project can read the custom xaml's, but my main project still can't reference them. I tried dragging the files over to the main project, and they still won't work.
I tried rebuilding the controls xaml's and C# code-behinds in my new project it still says:
The type 'local:ClickSelectTextBox' was not found. Please verify that that you are not missing an assembly reference and that all reference assemblies have been built.
This item is under the appropriate namespace and in the current project.
In visual studio go to TOOLS -> choose Toolbox Items. this will allow you either choose from an array of different components or browse around to find a dll that you would like to use.
EDIT:
Oh so you are trying to take customized xaml files that you already have written and modify them in a separate project? I would suggest one of two things.
1: right click your project name -> add existing, and add the xaml and xaml.cs file to your project at the same time.
if for some reason that does not work you can also try
2: creating a new xaml control (with the same name of the control you want to drop in) in your project and copy pasting the xaml code into that control, this should autogenerate the codebehind designer shell you are going to need. you can then go into the xaml.cs file and drop whatever business logic you are looking for. It is not the cleanest solution but sometimes the WPF editor gets a little funky when importing xaml files
I know it's an old post but still somebody may find it useful:) So! ... Make sure
1)You don't have public class outside of root namespace, check this
link
2)You are not mixing targets of your assemblies (unless you can't 100% avoid that)
For example, if you are referencing something like SQLite.Core NuGet (that has both x86 and x64 versions of SQLite.Interop.dll built in) in a project that is AnyCPU, sometimes it's easier to set application's target to x86 or x64 to solve the x86/x64 paths issues - but then you may get all these "type not found/control not built/assembly not found" and all that sorts of nonsense from Designer even despite your app builds and runs ok.
Hope that helps
Try downloading ReSharper's trial version, install it and then open up your code again. One of the awesome features Resharper has with XAML code is that it will automatically map objects to their appropriate namespace. I think this will make it easier for you and will show you a ton of ways to do things better. When I was first learning WPF it was honestly a godsend to use Resharper.

Cannot run Roslyn Samples under VS2015 CTP 3

I downloaded Roslyn code and built it successfully within VS2014 CTP 3. I am trying to run the samples that came with the source as part of Samples.sln solution. I can build Samples.sln successfully.
I try running ImplementNotifyPropertyChangedCS sample - I made the project the startup project within the solution and pressed "Start Debugging" menu item. As a result I am getting another VS2014 instance. I open a new project within that instance, create a property and try to refactor the property. I am not getting the option to Implement Notify Property Changed refactoring.
I checked the dependencies of the new instance of the visual studio - it does not depend on ImplementNotifyPropertyChangedCS.dll file. I looked at the output window of the first devenv instance - it seems like that ImplementNotifyPropertyChangedCS.dll was loaded but later was unloaded.
Please help.

Can't change a project's Default Namespace in Visual Studio 2013

I have a solution that includes various C# projects, and I just now noticed that I can't change the default namespace on any of them.
When I go to Properties --> Application on any of the project and change the "Default Namespace" field, a fatal error dialog pops up that says:
exception of type 'system.runtime.interopservices.externalexception' was thrown
At this point Visual Studio becomes unusable, as I can't close it or leave the screen, every click or button combination I press makes the same dialog pop up. The only thing I can do is terminate VS with the task manager.
I got around it by just renaming the <RootNamespace> node in the .csproj file
Maybe you should try to do this in another way:
Ctrl-H - Find: PreviousNameSpaceName Replace: NewNamespaceName
You can also right click the namespace in code and Refactor->Rename.
What is more: you can change the names of your projects, solutions, directories - etc. Namespaces, when adding new files, are generated using these names in fact.
I had to investigate the issue in our company and I found another workaround in our case. So I think it make sense to add it here.
Possible Solution
Check if you have more than one suo-File for the project/solution and delete the one which doesn't has the ".v12.suo" naming (better delete both)
Story behind:
We still have two Visual Studio installed (2010 and 2013) and some of our developer worked recently on 2010. So they had on the file system a regular ".suo"-File. Afterwards (some weeks later) they started to use 2013 (which created a ".v12.suo"-File).
We renamed both suo files, started VS2013 (which created the v12.suo) and were able to rename the namespace without a crash. In addition we had this issue not on all solutions. I didn't see yet a pattern, but in our case it happened mostly on solution with at least two projects and referenced project-libraries.

Categories

Resources