hope to see this as standard VS functionality, after all Xamarin Studio has such from what I know
1) After installing you have to restart VS2013 to see the template I think 2) the template icon shows a mobile phone, could show instead the same icon (with a language icon overlay, like C#) as the one shown inside the Solution Explorer pane (two overlapping rhombi) 3) WHY DOESN'T THE SHARED PROJECT ALLOW PUTTING FILE LINKS IN IT? SOMETIMES YOU WANT THE ASSETS TO LIVE OUTSIDE THE SOURCE FOLDER TO EASE COOPERATION (SAY VIA DROPBOX) WITH GRAPHICS/SOUND ARTISTS FOR EXAMPLE
As most architects know, this has been possible for a few years by manually baking your own MSBuild files. The heavy cost with this technique is keeping teams inline with the churn; often updating the builds gets missed.
Thanks for pulling this close to the VS experience. This makes a huge difference to many project roles.
Sharedprojects in VS2015 support VB.Net, but this Extendion in VS2013 only supports C#/VC++/VJS ?
Is there any plan to add VB.Net support, or do we have to use VS2015 on all machines in order to use shared projects with vb.net?
We need this in visual studio 2015 because you cannot add shared projects to web applications. The "Shared Projects" tab in the referrence manager does not show up in Web Project Types.
However I know it works because I can manually add them in the project file and it works fine.
I just noticed the following issues:
1. In the SPRM dialog, once I checked a shared project, I can't uncheck it. If I click the checkbox again, it adds the reference again, so if I click the checkbox N times, I end up with N <Import> nodes in my .csproj (although only one appears in the References node in the Solution Explorer)
2. There is no Cancel button in the SPRM dialog; so if I checked a shared project by mistake, I can't uncheck it (due to issue 1), and I can't cancel. Closing the dialog does the same as clicking OK: the references are added anyway.
Performance profiling shows that with a large solution (384 projects, sadly), this plugin will spend a long time updating UI controls with the list of available projects when closing the solution. Closing this solution takes 2 minutes, 90 seconds of which is the plugin updating the UI. Actually, it's Visual Studio being really slow at marshalling with the command bars, but it's still crazy slow. I believe the plugin also has an impact on loading the solution, for the same reasons, but I haven't measured.
I also have large perf issues, when opening ConfigurationManager and changing the platform and switch between debug/release. In the stack I see SAPReferenceManager.dll!Microsoft.VisualStudio.CommonIDE.LoadedProjectList::OnAfterInvalidateHierarchyItem takes a lot of CPU time. I disabled the Extension ,because I don't really do store app coding, this extension was only installed for testing purpose. The Extension should be only activated for Store App Projects and no other ones.
So - when would I use a Shared Project?
- for instance, if one created some libraries / components shared among solutions, would you use a Shared Project then and IF that's the case, how does TFS handle shared projects as sharing sources within TFS is not an easy task.
- or is Sharing Projects mainly used for sharing code among various architectures? (as in almost every sentence, which mentions Shared Projects is also mentions Windows Phone)
The reason that Windows Phone is mentioned is that the original purpose of a Shared Project was to provide a single place to write common code that would be used in both versions of a Universal App. The code that was phone-specific would go in the phone project, the code that was PC specific would go in the PC project and the common code would go in the shared project.
Like various things, people have discovered that shared projects can be useful for more than what they were originally intended, so the scope has been expanded. Currently, in my office, we are creating a second MVC application that is based on an existing application but with a few changes. We are using a shared project for controllers that are the same or similar in both applications.
The difference between using a shared project and a common class library is that the code in the shared project is actually compiled into the other projects that reference it. As a result, it's actually possible to declare partial classes with one part in the shared project and other parts in the project(s) that reference it. In that way, we're able to use a shared project for controllers that are similar but not the same. All the common code goes in a partial class in the shared project and then application-specific code goes in another partial class in the appropriate application project.
With regards to MVC, it appears that a shared project doesn;t support views at the moment. Presumably that will be addressed at some point but, for now, the Razor Generator extension and NuGet package can be used to put them in a common class library.
While working on my solution, the classes under the Shared Project lost the use of Intellisense. Is this something that is common or a known issue? Keep in mind this solution is very small and only consists of a few classes & isn't monstrous just yet.
Most notably its happening on my SqlDataAdapter and SqlConnection. At first i just needed to recompile the whole solution and then it came back. Now it's not working at all for any class in the Shared project space.
I have this entry in my SharedProject.projitems file
When built it appears in the .dll'r resources as:
<data name="dictionary2.xaml" type="System.Resources.ResXFileRef, System.Windows.Forms">
As you can see "Styles\" path is lost and if I reference this resource dictionary in App.xaml like this:
<ResourceDictionary Source="Styles\Dictionary1.xaml" />
it cannot be resolved and crashes. However referencing resource dictionary like this works:
<ResourceDictionary Source="Dictionary1.xaml" />
I feel it is a pretty easy bug, if only this project was open sourced... I'd fix it straight away :)