Visual Studio Tools for Unity 2.2

Hey forum folks,

We've just made the bits live for our new release: the Visual Studio Tools for Unity 2.2 (VSTU).

This is mainly a bug fix release, focused on fixing bugs in the VSTU side of Unity's support for Visual Studio.

This release fixes a few issues that we discussed in this forum, an important one is that we're now properly installing our package where Unity looks for it when loading the native support.

In the meantime, we're also working with Unity on improving how Unity starts and talks to Visual Studio when opening scripts.

Thanks for your bug reports!

Jb & the VS Tools for Unity team.

 

If I see it right there is only API level 3.5 left? What happend to API levels above them (3.5-5.3.2)?
Edit: Hm, in another Script the are also now all the other API levels. Strange.

 

@surogat, hey! The base class library in Unity 5.3 has the same API surface than the one in Unity 3.5.

 

With VSTU 2.2 I can no longer open Project Properties in Visual Studio 2015. It doesn't open for Unity projects (just nothing happens), but opens for other projects. Reverting back to VSTU 2.1 solves the issue. Upgrading to 2.2 breaks it again.

Is it a bug or intentional behavior?

 

Hi Alex,

That's intentional, as VSTU will always regenerate the project files over any change you could make in the properties window.

 

Ok then, it just feels a bit confusing.

 

@alexzzzz, as far as hacks go, you can use our API to remove the fact that we enforce C# 4 for your C# integration hack:

https://gist.github.com/sailro/3548b751faf821dbef7c

 

Is this new VSTU 2.2 part of the new Unity 5.3.2?

 

Hi there,

I have the same "problem" as @alexzzzz, I can't open the Project Properties through Visual Studio 2015. This is annoying because I'm trying to install a NuGet package and I get this error :

Could not install package "sharpconfig 1.4.9". You are trying to install this package into a project that targets ".NETFramework,Version=3.5,Profile=Unity Full v3.5", but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

I'm trying to install this cool project named SharpConfig which interacts with .cfg files : https://github.com/cemdervis/SharpConfig
Yet, I used the LangRemover.cs and put API Compability Level 2.0 in Unity, but I still can't install NuGet packages.

I gave a try commenting manually TargetFrameworkProfile and TargetFrameworkIdentifier attributes in .csproj and it worked, but it obviously disappears due to project files regeneration. Any clean way to solve this ?

 

The Unity installer always points to the latest release version of VSTU.

VSTU never supported installing nugets packages, so we removed the ability to try until we fix it for good.

What would be a good nuget package installation as far as Unity is concerned? We would need to copy the DLL to the Assets folder. We would need to distinguish the case where you want to use the DLL in the game code or in the editor code.

 

I couldn't point to a single package offhand, but this could get interesting. VSTU would probably need to support special NuGet targets because additional setup files may be necessary, especially if a package has multiple assemblies and they need to be mapped to specific versions of Unity or platforms.

To add to that, it should support importing .unitypackage files as they would allow the following:

1 - DLLs to be pre-mapped
2 - Destination folders to be handled in the .unitypackage

A potential scenario for this would be studios that use shared packages across multiple games. They could easily setup Team City (although the Nuget server option in TC is buggy), or setup a private NuGet repo and use it to pull those packages (this is the scenario I would use).

 

I am having this same problem and it sunk a whole day of development time for me.

We were using Unity, VSTU, and Visual studio to generate .csproj files for modules of code that we would then compile into DLLs. Part of this workflow included editing the .csproj files that were generated, and adding references to a few external DLLs.

Now, whenever I open a .csproj or .sln created by Unity and VSTU in Visual Studio, it doesn't recognize it as a C# project, I can't open the properties view for the any of the project files, and I cant add a reference to any external DLLs. Our whole pipline is broken.

The worst part, is I can't seem to find a link anywhere to VSTU 2.1 which did not have this issue. Since I can't seem to revert to the older plugin, I'm faced with rewriting huge portions of our pipeline.

So much for an update with just "bug fixes", all it did was remove functionality from the user in order to "hand hold" the developer through the visual studio process.

Now for how to resolve this:
1) Can I get a link to VSTU 2.1 without this bug that you think is a feature?
2) Can you make the project/solution locking or whatever is happening a toggle instead of forcing a leash on every developer?

 

The projects that VSTU generates were never meant to be compiled as a standalone DLL. They represent the state of Unity's compilation pipeline, and if you modify them from VS, the next time something changes in Unity the changes will be overwritten.

You can't for instance add a new reference to a VSTU project like you do for a standard class library project. With Unity, you need to drop the class library in the Assets folder, that's the only to get Unity to reference a class library.

Therefore, we're preventing users to modify the project properties for VSTU generated projects.

Now, if I understand correctly, you have a slightly different use case where you take the generated projects, copy them somewhere, and use that to create a class library. Then you just need to treat those projects as an actual class libraries and not as a VSTU project. Open the csproj, and comment the line with <ProjectTypeGuids>.

If you want to modify the generated project files each time Unity needs to regenerate them, you can do it by participating in our project generation using our API:

https://msdn.microsoft.com/en-us/library/dn940021.aspx

 

I will look into modifying the generated project like you said.

However if I am understanding correctly, you are assuming everyone using your tool does not grasp the inner-workings of Visual Studio, so you intentionally block functionality which is frustrating to not only me, but most likely many others since more than one person has ran into this issue in the week since the update. Not everyone uses visual studio, scripts, and DLLs in the same way so its frustrating that you assume so, and assume there are no use cases for build pipelines that are not the norm. We are a large team that needs to manage our assets differently than a single unity developer working on a project with one collection of scripts.

I understand that not everyone using your tool is familiar with or comfortable using Visual Studio, but maybe there should be an "advanced mode" which lets you edit project files.

I understand the csproj files are not updated when things change in Unity; I make edits to the .csproj files to find and include the needed .cs files automatically (not really difficult to do, not sure why unity doesn't just do this by default). These are issues I've seen and already made adjustments to in my system, so removing access to this options doesn't "fix" any problems, it just breaks them.

Instead of making this assumption and blocking the editing of files, this should be a toggle in the VSTU options or at least explicitly stated.

I'm pretty frustrated since I wasted so much time today trying to decipher what happened to our pipeline, so bear with me. I have been using VSTU since it was UnityVS and had paid seats for developers, so a drastic change like this really rocked me.

 

It kinds of sounds to me like you're sort of hacking a solution in place. There's a much easier / better pipeline for this and it can be done right from Visual Studio. Your modular code should be in separate projects included within the same solution. You have a couple of different options at this point, one being that you can set the build output for those projects to your unity /Assets folder, or you can do what we do in our Enterprise solutions for DI assemblies. We create a BuildCopy XML file as a solution item that contains the list of assemblies we need since we don't have hard references in our main project. Then we have a build action defined in the .csproj file that examines that list of assemblies and copies them based on the solution dir, or you could use a relative project path. You could have those as build steps within your other projects so they copy to your Unity project without ever manually editing the Unity generated .csproj file.

 

This was the eventual plan. We did it this way initially because it nice having a copy of a .sln and .csproj in the unity project directory in each repository that I could use to build a DLL containing the functuonality of the project in one file without any assets. These could be easily created from any project someone created with a few edits to the existing files, as potentially many could be created. It looks like now our pipeline needs to be a bit more robust and not rely on the generated project files as much. Thanks for the suggestion!

 

um, no. this is just plain messing about where it's not wanted imo. what if i'm doing some tests on the code and don't want to have unity open? this part wasn't broken.. so why 'fix' it?

grrr..

now i'm *forced* to define conditional compilation symbols in the unity editor, because i can't get to the project properties. sigh. so now i *have* to have unity open and bounce between them for something that could've been handled entirely (and was) in vs...

not to mention, now i have to hunt around and see how unity handles custom build events, if at all, which to be honest could have absolutely *nothing* to do with unity..

what about signing? or anything else in the project properties? am i now supposed to edit the proj file manually?

so after updating to 2.2, i'm spending more time dicking around with your 'fix', than actually doing what i set aside time to work on..

thanks.. </sarcasm>

 

Again...pointing out there are many in my situation.

For now, can we just at least get a link to download VSTU 2.1 that did not have this bug, so I can continue my development?

I don't want to have to rework my whole pipeline at the moment, and if I just had the old VSTU edition that worked perfectly I can continue, none of the new features in VSTU 2.2 are things I want. I definitely regret updating and most likely will stop with 2.1

 

This isn't really new and not brought on by VSTU. Unity has always regenerated the project file when you save within Unity, and it keeps its settings in metadata / etc. So if you defined compiler symbols in visual studio before, they would get replaced whenever someone saved the Unity scene anyway. If you really want to edit the project you can install Power Commands and edit the project file manually, but as far as the properties go for the actually game project itself, the only change is that you can't bring up the properties from Visual Studio. I actually don't disagree with this change because it offered zero utility before since any changes you made would be overwritten anyway.

 

it absolutely is... i could go into vs *only*, test some code and *never* have to even *open* unity.. all i wanted to do was test some compilation pathing logic.. nope, now i have to get unity involved.. not because unity was making me, but VSTU is...

in this case i don't care about the syncing.. how about this: focus on debugging. that's what i paid for. *not* to manage my builds, projects etc etc..

lastly, this is a force push. instead of telling us what we need, how about asking?

jesus, with all of the hand-holding going on these days, when does a developer get to take responsibility for *being* a developer? if i screw up my project, it's on me, as well it should be. that's how folks learn, not by coddling them with rounded corners....

 

VSTU 2.1 for VS 2015: https://dl.dropboxusercontent.com/u/102171874/vstu.msi

 

excellent, ty alezzzz

 

thanks!

 

I stand behind this change. We had far more reports of people that didn't understand why changing a property in VS was immediately overwritten when you changed something in Unity.

The VSTU generated projects are only a way to represent what Unity is doing. The binaries compiled by the project files are never used by Unity. With the MonoDevelop REST integration, Unity is moving to a model where you don't have project files anymore, and it's a good thing the nature of project files (that you can modify from the IDE) doesn't map to what Unity is doing.

If you want to share code between Unity projects, the natural solution as a Visual Studio user is to create a class library project. You'll have complete control over references, signing, debug symbols, post compilation tasks.

I'm not opposed to adding an option in VSTU to allow showing property pages, but that's a strong indicator you're doing something that's by definition fragile.

 

Then have them crack a damn book or google or RTFM. As developers, it's what we're supposed to do.

I read the changelog before i updated, it said nothing about that little 'fix'. The reason i wanted to update was because unity and vs both lock up *STILL* to this day when debugging on VSTU 2.1. In the changelog it said that there were fixes addressing this. Nothing about trying to manage my project. In the future, if you have more planned 'fixes' of this type, please let us know in advance.

Lastly, i'll leave you with some very good advice that was given to me once:

"A tool isn't a tool if you spend more time *trying* to do your job with it, than *actually* doing your job with it."

btw, just so that we're clear here. This isn't personal between you n me. It's personal between you and my tools, because you took a tool that i had grown accustomed to, warts n all, and was able to use it. Your reasoning for breaking it (imo) feels like pandering to the lowest common denominator. Suppose i updated your keyboard driver and figured "he doesn't use the 'K' key enough so i'll disable it." Then i'll make you use another app to type the 'K's. capiche?

Good. That's a start. To your second part: you're kidding right? What part of development isn't considered 'fragile'? Of course it's fragile, hell i could write code to bluescreen the crap out of my cpu if i wasn't careful, that's why the saying is there: RTFM. right?

LOL, sorry. Stop messing with my tools!

 

Except the majority of keyboard users actually use the K key so the comparison isn't valid. Only a handful of developers need to use VS standalone without Unity running to change symbols in the project properties. In this case it was causing confusion for far more users than it inconveniences.

There's a very simple solution by the way... just create a new class library project, throw it in the same folder. Unity won't import it, and you can add your project files to it. Then you can go to the project properties all you want and set symbols.

That's why I do for JSON .NET for Unity. I have a Unity project that has a test scene, etc that I use for final testing and publishing. I also have a .csproj project that has my code in it and I use it standalone to set symbols and build so I can test.

 

/facepalm..

what is it that you're not getting? i didn't buy this to manage my projects in any way, shape or form. i bought it as a debugger. they should focus on what it's intent was, and still continues to be, regardless whether it's free now or not.

vs is a world class development ide. monodevelop, is well, monodevelop. the *whole* reason i use vs is because i've *always* used it, since the beginning of 1998, and don't want to use monodevelop. it has the power and flexibility that i like and enjoy. why on earth would anyone want to hobble it because they're too afraid to tell their developer userbase to *learn* by RTFM. and in case you have no idea what that means? it means "read the f****** manual". how about we *expect* developers to know *how* to be a developer instead of hiding things away so that they don't have to learn.. ever wondered in part *why* there's a GC? most, if not all, of the developers back in the day understood not only programming, but the history of it as well. not just on some wiki, but lived it. that history gives invaluable context. it also means i know what's under the covers and more importantly, *why*..

but i also feel the same way, however harsh it may sound, that not all children should get a trophy. but i digress..

the fact that i still wanted to be able to open the settings in vs (god forbid).. what's next? figure out a way to clamp down notepad in the off chance that someone might edit the proj files manually? oh noes!

ffs...

 

LOL, and btw jb? it could even be a state button. when pressed and disables the properties; the text could read "i'm a user". while unpressed, and enabling the properties, it could read "i'm a developer"..

just sayin..

 

Maybe it is because I do not do a lot of C# scripting, at least nothing too cutting edge but can someone maybe give me a hint as to why Visual Studio is a solution.

In all honesty if I want a C# script in any of the projects I create with Unity I just write it on a text editor and save in a Assets/Scripts directory.

I have to assume that Visual Studio does something that helps and I have not yet been forced to do anything different.

Not yet at least.

 

Yes, that may very well be why you don't understand my reaction. Or it could be that I have a problem that someone decides to 'fix' it by taking functionality away from me because other folks are too lazy to learn their tools.

Visual studio isn't your only option, as well it shouldn't be, but suppose I wrote a plugin tool that arbitrarily took away that choice from you because I had folks complain that monodevelop or notepad was too hard? I've developed most of my career in visual studio.

This really isn't complicated to understand.

And btw, I don't mean to imply you specifically, just folks in general that wouldn't try to understand how the whole thing works before complaining.

 

It's cool. I appeciate anyone who tries to make something better.

I am kind of new to Unity and because my past experiences translate well with Unity, I am really loving this program.

In all honesty I have no previous experience with Visual Studio so I am not completely aware if it is an intuitive UI back-end friendly issue or if like say Dreamweaver is to managing complex web designs, that VS is maybe used as an aid to say... complicated game designs and managing the collaboration of multiple developers.

Either way, although I have previous coding skills, I found it interesting that when I first downloaded Unity I was requested to download a trial version of VS.

When the trial ended I did not sign up. Instead I just edited the file from Notepad++.

If VS has something that can aid in the efficiency of game design and development I will most certainly consider purchasing a license.

 

Ok, I get it.

I just asked because this was a VS thread.

I get of gist of the debate.

Apparently before the plugin there were workflows most optimal to advanced users of VS.

But the plugin forces advanced VS users to open Unity.

I studied monodev a little and am apathetic.

I have heard that VS does things to help coders but I really have little knowledge of what those things are specifically.

I am not sure if it will ultimately matter to me because I may learn to live without it not knowing how it can help me do the specific things I am doing.

We will see what the future holds but I am probably not going to buy a license to use VS until I reach a point where I need to consider more advanced solution.

 

There was one option that was removed and it's not a big deal which is why you only see one person ranting about it.

To actually answer your inquiry, there are a lot of pros to using Visual Studio if you're coding in C#. It's not buggy and crashy like MonoDevelop. The intellisense is very good, and it has excellent debugging capabilities. Those are just a few major reasons to use it. Once you get familiar with it, just being able to hit F12 on a variable to go to where it's declared, or F12 on a function to go into the code for that function is a huge time saver.

Also, you can pretty much ignore the "Trial" bit. It's Visual Studio Community Edition. It's exactly the same as Professional but with a slight licensing difference. If you have something like over 10 computers and a million in revenue you have to buy professional, otherwise you can use Community for free even for commercial use. It will install as a trial but once you set your MS account up and license it as Community you're good to go.

 

yeah, sounds about right, your comprehension skills are about as bad as your math..

 

In that case I will go back to my preferences and set VS as the default text editor. I am sold on the Community version.

If my company made a million in revenue and more than 10 developers per project then having to buying the Pro version would be a great problem to have.

 

My math is solid, as well as my comprehension. It all keys on the term "ranting". While a few have commented, I've only seen one public production with generous hand waving and squeaks about moving the cheese.

 

Because what? Because *you* don't think there's an issue, therefore I should appreciate your 'from the sidelines' bs and not accepting your minimalized view?

Methinks thou appreciates himself muchly..

I'm not the only one this affected, and there are probably more that haven't posted. So, other than to attack me personally (trolling), how does me asking for that functionality back or my frustrations with it, affect you at all?

Right. It doesn't. So get down off the pedestal that no one has placed you on, but yourself, and stop being an ass.

btw, just looked you up. seems you have a comment or something to say about everything.. guess i'm just one of your latest targets, hmmm? nevermind that you yourself have complained in plenty of threads yourself. disingenuous much? lol

 

FYI: VS will not let me use the program as a trial anymore. Or at least I could be missing something.

 

I'm not 100% sure what the process is since I have Visual Studio from MSDN, but I think on the screen where you enter your license / update your license you can choose to use Community Edition. That's what you want to do. It's full blown Professional and not a trial.

 

You're taking it too personally. We don't live in a Utopian society and not everyone is going to agree with you. Brow beating the topic isn't going to gain you any traction. I understand your concerns and they are valid, however there are other ways to go about it, of which I outlined.

 

It's also possible that you need to login with a Microsoft Live ID.

 

Refresh my memory, who are you again?

 

Thanks for moving beyond your own ego to have a reasonable dialogue with the community that uses and supports your tool.

 

Huh, I ignored this "VS Tools for Unity 2.2" thread thinking "Who is still using Unity 2.2"?

Otherwise I'd have posted this question here:
http://forum.unity3d.com/threads/disable-visual-studios-mirroring-of-debug-log-output.388610/

 

I've just realized that VSTU 2.2 breaks a workflow trick that I used to use.

From time to time I want to run some parts of my project code without running the whole project. The main reason usually is to be able to profile it using a standalone .Net profiler, that gives much more useful and easy to read information about my code than Unity's profiler does.

The way I did it previously:
1. Open the project properties window in VS.
2. Temporarily switch the project type from "class library" to "console application".
3. Specify some existing static method as an entry point for the application.
4. Run the code right inside VS or build an executable and run it from a profiler.

 

Just found this topic, since I also just noticed that VSTU is stopping VS from opening the project properties. I'd like to change the Code Inspection settings for the projects since Update 2 for VS 2015 added a bunch of C# 6 specific IDE code hints that are all unusable in Unity. I also agree with the opinions above that I most definitely DO NOT want VSTU to disable basic features in VS 2015 to "help" me. I just want to use it to debug.

 

Been trying to show the visual studio tools menu for an hour, only to discover it has been removed(but I can still see it on a Unity for osx).
So how do I disable console output in VS? In the doc you say that the menu is useless so it has been removed, but none of the options of such menu are present in Unity settings!

 

Hi. Just follow on this. Not able to open the project property in Visual Studio is a bad move\bug or what ever it is.

I want to push my code to the Xbox over a LAN. To do this I must go into the property and change the debug to a remove device. So the Alt+Enter to get in and the screen flash and goes away = no testing of Unity3D games directed on the Xbox One - please make it so we can or can someone tell me a work around.

Thanks in advanced, Wayne

 

I got no response asking the same question. See my link a few messages above for some hacky partial work-arounds.

 

Thanks, but I wanted to disable it especially for debugging since I don't know why sometime it continue to refresh even when I am not outputting anything, making it hard to see the watch variables.