I'm having a bit of trouble here, in our company we have a self rolled DA layer which uses self referencing generics. In Visual Studio 2010, the IDE was perfectly happy with this, however 2012 seems to be having difficulty, even though when we build, it succeeds.
Here is an example:
The DataObject definition is as follows:
[TypeDescriptionProvider(typeof(HyperTypeDescriptor.HyperTypeDescriptionProvider))]
public class DataObject<T> :
INotifyPropertyChanged,
IDataErrorInfo,
IEditableObject,
IDataObject
where T :
DataObject<T>,
new()
I realise it isn't the simplest of definitions, but its legal, and it builds perfectly fine.
However, this 'issue' causes intellisense to fail, as well as the 'Go To Definition' function, which needless to say is frustrating.
I've tried removing and re-adding the references, but the issue persists.
VS2010 is perfectly happy and is what I have gone back to using, VS2012 is very nice and responsive but if this issue persists its a deal breaker.
Anyone got any ideas?
Want to make a couple of things clear, this issue is an intermittent one (which is a pain as its really hard to track the root cause).
It breaks intellisense and 'go to definition' everywhere, not just for the class with the error.
I'll have a go at building a example solution to submit to connect, but time isn't on my side lately.
This can happen if you open the same solution/project with two instances of Visual Studio (even two Visual Studio 2010 for example). The Intellisense mechanism uses .NCB files that Visual Studio instances cannot really share. In this case, Intellisense behavior is strange.
Sounds silly, but I run into similar issues with new code that gets introduced or changed with intellisense. I tracked it down to basically needing to perform a save all, or sometimes even clean and rebuild / compile before it intellisense properly acknowledges the code being valid.
A similar that happens on occasion in VS2010 too that can be duplicated if you make a class structure, then edit code on another class to use it, then bounce back, hack out class functions and add new ones without any saving.
Sometimes, and this isn't always the case ReSharper can cause issues with references and GTD functionality. Do you have it installed?
Related
Visual Studio has a "Refactor Rename" feature where I can right-click any type or member and rename it, and it will update all references within a project or solution to match. Is this functionality accessible from MSBuild command line tools, without having to open Visual Studio?
(I'm doing this because I have a project that is so large that Visual Studio runs out of memory while attempting to calculate where the rename is needed).
As far as I'm aware that's not something that's available outside of Visual Studio; although you probably have a couple of avenues available for getting it done.
The first thing that I'd try is using a lighter editor, VSCode, Atom, etc. Something that uses less memory, but will still hopefully let you get the rename done. You might have to use a regex find/replace to get it done; whether that's an option kind of comes down to if you can make an accurate regex.
If you can actually get the project open in VS with no (or less, at least) problems, then you could also start unloading projects that aren't relevant to the rename. If you know that it's only available in certain projects then unload everything else, perform your rename, and reload the projects. If it's everywhere then you might still be able to do something similar to this, perform the rename in a few projects, unload them, load the next few, rename, etc. Although I'm honestly not 100% sure that'll work, I've never attempted it.
Regardless of what you try, if you haven't already be sure to have your code in source control just in case. I'm sure this is doable, but maybe not via the VS command line.
No. There is no shipping msbuild target, task or tool to rename variables from the command line.
You could of course write yourself. :)
But I highly suggest using Visual Studio Code as an alternative to Visual Studio for loading large numbers of projects. It's an outstanding cross platform IDE. And who knows, perhaps someone wrote a plugin for it to rename variables...??
I'm currently developing an app on our companies portal and yesterday started noticing that I wasn't able to reference external classes or methods from references.
My colleague put the solution on his computer and committed his code with all the references working fine, and I opened up his code and the references have stopped working and still can't be found.
I have deleted the website cache and other user options but had no luck so far.
One reference file is an external VB class file and the other was simply calling "request" from Web.UI.UserControls. (I got around this by using HttpContext.Current.Request.QueryString , even though "Request" worked on my colleagues computer)
Is there any options on my Visual Studio that would make the same code break compared to his? I contemplated a reinstall but it's a lot of time wasted and the problem may surface again.
Edit. I'm on Visual Studio 2013 Ultimate
You can enable assembly binding log, and use fuslogvw.exe to see what is going on behind the scenes. It will allow you to know more details on the error and think in possible solutions.
http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.100).aspx
I am writing a wrapper around two different versions of a communication library that work with different versions of my company's database. These communication libraries have classes with identical fully-qualified names, so I am loading the references into different aliases; I've tried it with one or the other in the global alias and with both in non-global aliases, and in both cases Visual Studio 2012 complains that I have compile errors. In specific, in both of my wrapper classes, I am fetching a connection from a factory method
extern alias MyAliasVersionX;
using MyAliasVersionX::Example.MyNamespace;
...
private Connection _connection;
...
_connection = Connection.Create(environmentName); // this returns an Example.MyNamespace.Connection--but this is where the compile error happens
The code is virtually identical in both classes; the biggest difference is the version on the alias in the using statement at the top. In one class (it appears to be whichever reference is listed first), everything works fine, no error. In the other class, Visual Studio tells me that the line noted above will produce a compile error because Connection.Create() returns the other version of Connection object (i.e., MyAliasVersionY::Example.MyNamespace.Connection instead of MyAliasVersionX::Example.MyNamespace.Connection).
Here's the important part: when I actually Build the project, it compiles fine and runs fine, and the error showing in the Error List pane disappears... until I make any change to the code, at which point it comes back, still never causing a Build error.
Is this a bug in Visual Studio? If not, what am I missing?
This is a bug in Visual Studio dating back to VS-2008, according to Microsoft. It won't likely be fixed until a major overhaul of VB.NET/C# editing (called "Roslyn") is released. (If you're dissatisfied with that, upvote my Connect feedback below to let Microsoft know!)
https://connect.microsoft.com/VisualStudio/feedback/details/786107/visual-studio-shows-error-cs0029-for-types-in-non-global-alias
I'm using Visual C# 2008 Express. This is the first time I've had this error in years, the last time I had it was around the time I started programming.
I have no idea what it actually means or why it suddenly came up, it seems rather ambiguous for what the error message says. All I know is that throughout my app, I inherit a lot of the main windows from a ThemedWindow class I came up with to give them a custom appearance, there are no errors in that code and everything was working 100% perfect 20 minutes ago.
The error in full:
Warning 12 The designer could not be shown for this file because none of the classes within it can be designed. The designer inspected the following classes in the file:
InheritingWindow --- The base class 'ThemedWindow' could not be loaded. Ensure the assembly has been referenced and that all projects have been built. 0 0
I get that for every form that inherits from ThemedWindow, and several other errors because the project won't build far enough for everything else to work.
Just before this happened I updated the font on all forms and sub-controls, the project even built and ran after I did that, then this happened for absolutely no clear reason.
I've tried the classic rebuild it, delete build files, reopen Visual Studio etc, but nothing seems to work at the moment.
Does anyone know how to fix this?
Build your base usercontrol class with AnyCPU option.
These problems were caused by an unfortunate bug in Visual Studio. I had other errors (not warnings) in some code, even though nothing else directly depended upon it, which played a part in this whole situation.
I could be wrong in explaining it but here's what I think went wrong: for some reason (bug), it totally forgot about unchanged objects it had already compiled before, gave me the actual errors I had in my code, and a bunch of other warnings because it wouldn't go past that point. I couldn't get into the designer for forms that depended upon ThemedWindow because I'm guessing ThemedWindow hadn't recompiled before these errors occurred.
Once I commented out the erroneous code as a quick fix and rebuilt the solution, everything compiled successfully.
As of writing this, this seems to be working properly in VS 2019 16.11.13.
It is not, however, working in VS 2022 17.1.6...
In VS 2022, I tried all the other fixes mentioned here, or they were not relevant:
AnyCPU is already set on the solution, never changed from that
The base class was never modified since it last worked, and so wouldn't need to recompile (plus this seems a moot point since it works fine in VS 2019)
While changing the base class temporarily to System.Windows.Forms.Form did get rid of the original error, it popped up a load of other errors of missing framework references and other non-problems.
The project is referencing .Net 4.8, (latest at time of writing this) and is not different from VS 2019 to VS 2022. Either way, can't reference non-existent newer version, and I doubt referencing an older version would fix this without breaking much more.
I saw a fix somewhere else of running VS as administrator and then rebuilding. This also did not fix the issue.
So I guess my fix for this is to downgrade from VS 2022 to VS 2019...
In my case (VS 2015 Pro) none of the above helped. Only after changing the target framework to different (specifically newer, from 4.5.1 to 4.5.2) and recompiling did the Forms Editor load the form.
Before changing the target framework I tried cleaning the solution, removing and adding the references (the base user control was in different dll), manually deleting all bin and obj folders after cleaning the project, restarting VS, all to no avail...
I have this problem too, with VS 2019 version 16.11.2, so I guess this bug will never be fixed.
My workaround, since my BaseForm class does all its work through code at runtime and has no functionality that would affect the designer, is that when I need to use the designer, I just temporarily change my window's base class. That is, change--
partial class MainWindow : BaseForm {
to
partial class MainWindow : Form {
then do the design stuff, and then once the designer is closed, put BaseForm back.
This may work for you if your base form class also doesn't do anything that would have an effect in the designer.
I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.
Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.
When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help
I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.