I have been using vs2013 for my Unity game with VS Unity plug-in.
Intellisense is working just fine except for my partial classes.
For some reasons that I cannot fathom, Intellisense's complete word function does not work.
If I write down the whole method/variable, it does not show any errors BUT when I'm half done with my typing, it shows up on very rare occasions.
I am currently wondering what may be the cause of this problem but not even close to finding one reason.
Could be that my partial class (split into 2) is large since both added up contains more than 20000 lines (which is the reason I split them).
But then, its merely 20,000 lines of code and is just a medium sized project compared to what other projects may contain.
Any help would be appreciated.
Related
I've recently been given a Unity VR project to tidy up. Very messy, wasn't even on Git. It consists of four Unity scenes, but each one lives in it's own Unity project. I need to have all of them in one project for the build, which is where the current problem lies. The scenes have a lot of scripts in common which were copy pasted between the projects. Some of these are absolutely identical, others have one or two lines difference.
From my research namespaces seemed the best way forward, so that I don't have to go and tweak everything manually. I gave the base scene a unique namespace, worked fine. I imported a second scene as a package and gave it a different namespace.
Now I get a bunch of compile errors to do with the VR scripts from Valve Corporation, e.g.
Partial declarations of 'SteamVR_Behaviour_BooleanEvent' must not specify different base classes
Duplicate 'Serializable' attribute
The namespace 'Valve.VR' already contains a definition for 'SteamVR_Behaviour_BooleanEvent'
I don't understand these scripts and don't want to (and shouldn't need to) mess with them.
An example of what causes the last error is having:
/// <summary>This event fires whenever a change happens in the action</summary>
public SteamVR_Behaviour_BooleanEvent onChange;
/// <summary>This event fires whenever the action is updated</summary>
public SteamVR_Behaviour_BooleanEvent onUpdate;
/// <summary>This event will fire whenever the boolean action is true and gets updated</summary>
public SteamVR_Behaviour_BooleanEvent onPress;
And then this further down in the script (SteamVR_Behaviour_Boolean.cs):
[Serializable]
public class SteamVR_Behaviour_BooleanEvent : UnityEvent<SteamVR_Action_Boolean> { }
Each BooleanEvent gets highlighted.
Am I missing something in my namespace procedure or does anyone know a more efficient way of resolving my issue? I've spent days with this already so any advice would be greatly appreciated.
What I ended up doing was this:
(I cut corners a lot this way and honestly didn't think it would work, but it did somehow.)
-Selected base scene.
-Imported next scene as a package, upon import deselected scripts that showed up with the little gray symbol for being potential duplicates.
-Deleted any duplicate scripts or folders of scripts that were causing errors and didn't automatically get picked up as duplicates when importing.
-Refactored the namespace for the scripts from the imported scene. The Rider IDE has a great way of dealing with this, highly recommend getting the evaluation license just for this feature. This tutorial steps through the namespace refactoring https://www.youtube.com/watch?v=vLrGdx-Ob3g just make sure to switch your IDE inside Unity from Edit > Preferences > External Tools > External Script Editor. Otherwise Rider won't link up to Unity and you won't be able to refactor.
I'm not sure how to properly word the title, but here is the situation:
We have a massive solution with about 130 projects in it. There are some redundancies in code, namely a particular LookupButton control we've created. For some reason, instead of being created in the Infrastructure.CommonControls project that all modular projects reference, this LookupButton was created numerous times in the various modules. Quickly poking around through a few of the projects, I found 5 different versions of this control but the only difference is its namespace. All of the code is 100% the same.
I've been tasked with creating one of these LookupButtons in the aforementioned Infrastructure.CommonControls project, and then removing all duplicates from the Module projects.
How can I do this while causing minimal blowback in all of the Designer.cs files that will be looking for MyModule1.LookupButton, MyModule2.LookupButton etc. ? I know I have a backup with SVN but I'm afraid to even start and get inundated with errors...
Easiest thing is to just remove the redundancies from one project, then fix the compile errors in that project until it compiles again.
Push your new code to the SVN and then move on to the next project. There isn't much else you can do.
The following should work:
Ensure you have the current state in SVN
Add the code to Infrastructure.CommonControls
Remove the code from all projects that it does not belong in
Compile the solution
Go through all of the errors. For each occurrence of LookupButton errors, right-click on LookupButton in source control, pick Resolve, and select the option to add a using statement.
You should only find yourself correcting the 5 projects that had their own internal copy of the control, not all 130.
Additional info: I thought it might be helpful to say that my forms and classes are in the same solution as the already updated forms.
In our company we have this project which 3 people are working on it. One works on the database part, me and another colleague of mine are working on making the UI ready and relating it to database which is MS SQL Server 2012 and we are programming in C# in VS 2012.
The problem is that I made this one form ready, but the server version is ahead of me. That is, if I check in the whole program, I will damage the project as some forms has changed and the version I have is older. I tried right clicking and checking in only the forms and classes which I, myself made and I have their latest version. They check in without any error or anything, but the problem is, when my colleagues or myself(after deleting my source project) try to get latest version, my forms or classes doesn't show up.
We also tried to check in the whole program but only accept those pending changes which are made by me, still no success.
The problem is, we are kinda afraid to play with the server version as a lot of effort has gone into it.
Any help will be really appreciated as I'm stuck with this problem and the manager won't give me more parts of the program to make until we can come up with some way to deal with this.
You haven't mentioned merging at all but I think this is the answer to your question.
When you work on an older version of the code (because your local code is older, or maybe the whole branch of the code is older), you need to merge the code into the newer version. When you merge, any potential conflicts are detected and you can resolve all of them manually. There's obviously tools to help you - one is built into Visual Studio but you can replace it with an external tool which may work better for you. Either way, you need to decide how to merge the code. You have a few options:
take the whole code from the source (old code in this case),
take the whole code from the target (new code in this case),
merge the changes and take bits from each version based on your knowledge of the changes and how the code should look like.
As for why the forms don't show up, you probably didn't check in the changes to the project file so the new files are not part of the project as it exists in Team Services.
Everytime I move to Designer View my whole designer.cs code is messed up :
VS Designer reorganizes code blocks and puts an irritant verbose prefixes like "this.whatever"
and fully qualifies objects using "System.Windows.Forms.whatever"
I Know that "Designer.cs" is not intended to be edited but I need to do some GUI code customization from time to time and would like these to stay as I changed them.
How to avoid that ? (Guess this is too funky for VS to handle)
(Actually I am just avoiding the use of the designer and do it all by hand, the good old way)
Update : I am surprised to see the herd-like reaction towards this question. Sorry if it is disturbing, but it is interesting to see that, before hitting me on the hand saying "DON'T DO that, it's Bad", NO ONE asked WHY I wanted to do it. IMHO the question is relevant and that's why : Many of the "auto-generated" code is rubbish and of absolutely no use, it does need some enhancement. One example (among soooo many others) : Why generate a Size/Location property when the control's Dock Mode is set to Fill ? I wanted to take advantage of the benefits whithout the drawdowns. Anyway, I'll keep the short answer : You take it ALL (with the rubbish) or leave it ALL.
It's simple: don't edit the designer code. Those warnings are there for a reason, and for Visual Studio to work correctly it needs to own that file.
This is a partial class: everything you need to do, you can do in the matching non-designer file for that class; this includes all your control declarations and other things. Since you're trying to avoid the designer entirely, let visual studio have that file and just put everything in your normal .cs file.
Update:
Based on the comment, I want to add the following —
Either use the designer or don't use the designer. Don't be wishy-washy about it. If you're using and relying on the designer for some things, you MUST leave the designer's file alone.
If you're avoiding the designer, then really avoid the designer. Everything it does you can do in your own code (except of course for the visual queues, but even that can be done better via prototyping). You can even create your own additional file for the partial class to keep designer-like code in.
If you're only using the designer as an occasional code generator to help reduce some boring typing, do that in a separate project or on a throw-away form in your existing project and just copy/paste the code over.
The designer should only be writing code in FormName.Designer.cs which you should not touch. Visual Stuiod declares a partial class implemented in two files - one for the designer, and one for your code. I'd be surprised to hear that the designer was rewriting the non-designer file.
If this doesn't help. please give more details of which version of VS you're using, which files are being rewritten, and which bits of those files.
You can always extend the designer class by putting your custom code in another cs file. The designer can't touch that and the compiler will compile your additions to that class. If you're doing something like adding properties or methods its super to simple to do:
// MyWinformExtension.cs
partial class MyWinformName
{
public string Foo { get; set; }
public void ProcessData()
{
// do some processing..
}
}
Voila! That's how you add your own code. You can't alter the designer code because it will be re-written ALL DAY LONG by the IDE. That's why there are warnings in the source and why everyone else is telling you the same thing.
About 2 years ago I worked on a C# project, using MonoDevelop V1 and later V2 (beta release, compiled from source, what a mission) under Fedora. The project went dead. Now I am bringing it back to life, but I have changed my development platform to Debian (testing, i.e. squeeze), which has MonoDevelop V2.2.
I am mostly very pleased with the features of V2.2, but I have a nasty little problem. All the code compiles OK, but at the end of the compilation run I am left with lots of warnings as in the subject line. Obviously, as soon as I try and run the application, I get exceptions left, right and center when I open anything that uses these widgets.
The funny thing is that the library containing the widgets compiles just fine. But somehow these widgets (it's not all of them, only one or two) don't get exposed on the interface, and then subsequent dialogs or windows using them throw the above warning.
Has anybody had this problem? I have googled this and all that comes up is Michael Hutchinson throwing his hands in the air and saying "sorry, can't help here". I really need a fix for this, otherwise I will have to rewrite substantial chunks of code from scratch.
I would recommend trying MonoDevelop 2.4, but in any case here are some hints.
If you have an assembly which uses custom widgets implemented in the same assembly, you may be having a chicken-egg problem, since MonoDevelop needs the built assembly in order to find the custom widgets, but that's the assembly you are trying to build. This problem can be easily solved by building again the project after you get the warnings you reported. Beware, you have to build, not rebuild, since rebuild will delete the assembly and you'll hit the same problem again.
If you are not having the above problem, or if the solution doesn't work, the problem may be that the objects.xml file that contains the information about the exported widgets is not properly updated. You'll find that file in the project that implements the custom widgets, in a hidden gtk-gui folder. Open the file and check if the all the custom widgets are declared there. If a widget is missing, try opening the source code file of the widget and do a small change (e.g. a whitespace change) and then build the project again. MonoDevelop should be properly updating the file.
If you are still having trouble, please file a bug report.
I think I found a way out. Not sure whether this is the "official" method, but it seems to work.
In this library a normal widget's class definition starts like this:
namespace Amino.Common
{
//! A text entry combined with a pop-up date selector, very useful for otherwise busy dialogs
public class DatePicker : Gtk.Bin
{
If I now add two additional declarations right in front of the class statement, like this:
namespace Amino.Common
{
//! A text entry combined with a pop-up date selector, very useful for otherwise busy dialogs
[System.ComponentModel.Category("Common")]
[System.ComponentModel.ToolboxItem(true)]
public class DatePicker : Gtk.Bin
{
then
That widget gets included in the objects.xml file and
The entire solution compiles as expected (and runs as expected).
Maybe somebody could shed some additional light on this, I would love to understand this better.