I'm building (read: trying to build) a Visual Studio integration package, which contains some custom highlighting and intellisense. The language part is working fine, the package is being loaded in the IDE, installing on non-SDK machines without problems.
However, here's one annoying thing I can't get to work. I want to see my package details in the about box (which shows all the installed packages like Resharper), ditto for the splash screen.
According to the documentation, the method to do this is to implement the 'IVsInstalledProduct' interface. I did this, following the instructions on MSDN, but it simply doesn't work! When I put breakpoints on the methods it seems like they're never called. Hopefully there's anyone here who can enlighten me on why this doesn't work like it is supposed to.
Note:
I also ran devenv.exe /ranu /rootsuffix Exp /setup from the VS2008 command prompt, as recommended in other articles about this.
Did you register your extension under the HKLM\Software\Microsoft\VisualStudio\versionNumber\InstalledProducts registry key?
If it's a managed package, don't forget to apply the [InstalledProductRegistration] attribute to it, which will handle the creation of that registry key.
Related
In my visual Studio i have reached a point for my Xamarin Forms project, where i cannot build it, neither in debug or release mode.
In release mode, Linking on my Android project is set to "Sdk Assemblies Only". Having it set to this, i get following error.
I have tried setting linking to "None", like it is in debug mode, but that just causes a seperate list of error, which is even more confusing.
The errors in the image above, are in total 11 errors in Visual Studio.
These errors arouse after i had to increase the targeted Android version from 9 to 10, to support Googles Api requirement for new apps on Google Play. The updateing of Xamarin Form from version 4.4.0.936621-pre1 to 4.8.0.1560, might also have had an effect. Prior to changeing the targeted android version, it did however build just fine in debug mode, even with the higher Xamarin Forms version.
I am using Visual Studio Enterprise 2019 version 16.7.6, at the moment, if that is any help.
I have also implemented option A of the Workaround in the following link, to avoid the bug that the link talks about. This is another thing i thourght were good to mention, incase it has any effects on the result. Bug Workaround
Take note that the secound set of errors mentions a file called "proguard.cfg". That file does exist at the mentioned location. What is confounding is why it is mentioning that file, as i have not set Code Shrinker on the android project to anything, ie it is blank.
It is not a necessity to solve both sets of errors. That said, solving the first one, might simply mean that is also shows the secound set of error in the scenario where it is currently showing the first error. Because of this, it would be ideal to solve both errors, but at minimum the secound one.
Feel free to ask for more information. I can howerver not supply a packaged solution, with the errors, as it is for a company project, where i am not allowed to disclose the code. I tried to include the errors as text, but StackOverflow, sees it as code and therefore expects a specific formationg. Feel free to ask for it in text, if you need it, and i will try to supply it.
I have created WPF application solution, added a third-party(cloned git repo locally on my machine) library(Class Library output type) project to the solution, added the library project to my solution:
And then referenced it in WPF Project settings:
When a library throws an exception, I get this in Visual Studio:
I can edit the library project, edit the WPF project, compile everything and it will work. But for whatever reason when an exception is thrown I can't debug the library. How do I fix this?
I fixed Source Not Available error fix by unchecking Use Managed Compatibility Mode Checkbox(checked checkbox causes error to appear) in Tools-Options, Debugging-General:
If someone reads this and knows why Use Managed Compatibility Mode was checked and why I couldn't debug my library because of it, please tell us. It took me few hours of googling, asking people around, and trial and error, until I found out that it was my options(after I decided to reset them to see if it was them). I didn't change this checkbox by myself, I would have remembered it. It was like that from the start. I only export my options from older versions of Visual Studio(Visual Studio 2015 > 2017 > 2019) to preserve code style and other options I like.
We are using a C++ visualizer which visualized the class content to DataTip using IDkmCustomVisualizer. Something what natvis already has but more advanced. The extension is written in C# and worked beautifully in VS 2017. Since we switched to VS 2019 it stopped working due to new mechanism introduced in VS 2019 (external process).
https://learn.microsoft.com/en-us/visualstudio/debugger/visual-cpp-custom-visualizer-compatibility?view=vs-2019
Of course if I disable the "Load debug symbols in external process (native only)" option in VS my extension starts to work. However our project is huge and we like the new external process mechanism.
I also tried to add WorkerProcessSupported="true" to my vsdconfigxml. Based on:
https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Worker-Process-Remoting
However my visualizer is not called. I was not even able to get work the provided C++ extension example:
https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Cpp-Custom-Visualizer-Sample
The Worker-Process-Remoting code mentioned to split my class. Unfortunately without any example/tutorial I'm not able to do it.
Any advice how to solve this?
Many thanks for any help :-)
I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:
Edits were made which cannot be compiled. Execution cannot continue
until the compiler errors are fixed.
As an example of the sort of change I'm talking about, I've tried adding this line in various methods:
Console.WriteLine("foo");
When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.
Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.
I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.
Edit:
As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.
Edit 2:
I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).
I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:
<Assembly: AssemblyVersion("3.0.*")>
The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:
When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.
After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.
This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.
Edit: here's the bug report I filed.
This happened with me in a .net 4.8 app with Visual Studio 2019.
I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.
As commented above by #Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.
In assemblyInfo file (of the project present in error) Change:
[assembly: AssemblyVersion("1.0.*")]
To:
[assembly: AssemblyVersion("1.0.0.0")]
It Solved for me.
An important thing to say is the use of wildcast '*' make the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.
In Visual Studio 2019:
New csproj/vbproj with non-sdk style projects file are generated with:
<Deterministic>true</Deterministic>
And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.
I recommend considerate other ways to version the assembly.
More about Deterministic:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/
One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.
My builds and runs fine in Visual Studio, however when I run a Nant task to compile the website, it gives me an error:
[path]\ContactView.ascx
error CS0117: 'System.Web.UI.Usercontrol' does not contain a definition for 'Name'
I have a UserControl called ContactView that has another UserControl called ContactForm. Contact Form is the one who has the Name property (declared inline, there is no .cs file). I don't get why the error is on the parent UserControl, or even why it is complaining at all.
The code seems to run just fine when VS2008 builds and compiles it.
Any ideas?
I know the nant build scripts work for my 2.0 website, and in this websites web.config I added the 3.5 compilers. Is there anything I'm missing?
Edit: This error is actually showing up for every property on this user control and a few others. I don't know if it a single instance of this error is causing multiple failures or if all user controls are really invalid.
Update: The error has to be related to v3.5 of the framework, because it's also complaining about auto properties. When I switch them to have a backing field, it'll work.
It looks like you'll either need to use NAnt 0.86 Beta 1 or go with Palermo's fix. Use the -t option on the command line to target the right version. You'll also want to insure you have .NET 3.5 (and probably SP1) installed on the build server.
It's often easier to shell out from NAnt to MSBuild, since the latter supports .sln files.
It looks like the problem was that when you compile a website in updateable mode, you are not allowed to call public methods/properties in a user control with no code behind.
Once the code was moved to a .cs page, it worked.