I have an universal app, which contains shared project between Win8\Phone project. And i have some winRT component(project for background task), so how i can link from background task's project to shared project in universal app?
The Shared Project Reference Manager extension will enable this functionality for Visual Studio 2013. Once that extension is installed, you can browse and add shared projects as you would add any other reference to a project.
There are two caveats to be mindful of:
The extension adds an entry into your project file (.csproj). That entry has a condition on it that only adds it if the shared project file path exists. While perhaps seeming innocuous, this can lead to a bunch of orphaned entries in your project file if you rename, move, refactor things, or, if there is an issue with the shared project on disk such as changing its location, you only find out about it at compile time, not when the project is loaded.
As noted in comments for the extension, the extension causes performance issues with Visual Studio 2013 when you have a large number of projects, especially during startup/shutdown of Visual Studio.
Visual Studio 2015 has built-in support for shared projects, and provides a much richer set of functionality baked into the IDE:
http://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/
Related
I have been working on a class library that generates c# projects from an existing c# project. Right now I have the template project in a specific folder on my machine but what I really need is to add that template project to the class library as a resource, so I could distribute the dll. Any suggestion will be very helpful.
If I'm understanding this correctly, and you're saying you've got a project that produces new C# projects (so .csproj and .cs files) and you want to add those as a resource, then I'd zip them up and add the zip as a resource.
Also have a look at the way new templates in Visual Studio are distributed. Within Visual Studios program files you'll find the built-in templates for example "C# Console Application" and "VB.NET WinForms" in the default path "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ProjectTemplates", however you can always download new ones from online and add them to Visual Studio, I'm guessing they could be zip or some form of packaged file.
There's information from Microsoft on how to create your own project templates and mentions about zipping them up https://learn.microsoft.com/en-us/visualstudio/ide/how-to-create-project-templates?view=vs-2017
There's also a guide here on how to create your own project templates https://www.ecanarys.com/Blogs/ArticleID/180/Create-custom-project-templates-in-Visual-Studio
Having a look around at distributed project templates, they mostly come from the Visual Studio Marketplace.
Video 18 of this series on the Microsoft Virtual Academy might help you.
Creating and Adding References to Assemblies
https://mva.microsoft.com/en-US/training-courses/c-fundamentals-for-absolute-beginners-16169?l=Ry6jz0QIC_5706218949
I am completely new to C# development and Visual Studio, and just started working on an existing project for an app server. I downloaded Visual Studio Community for MacOS and opened the project's solution (.sln) file. I have managed to get the solution to build, but every time I open it, a popup window appears, displaying two warnings like
Projects with non-local source (http://...) not supported. 'http://localhost:<some port number>'
I couldn't find any references to this specific message. What does this mean? Should I worry about it?
It means your solution has a project defined in it that VS doesn't understand. This typically happens when a solution is originally built on one platform and then is opened on another.
For solutions built originally on Mac OS, which uses Mono for .NET, generic projects use the .mdproj type. VS for Windows doesn't understand these. Likewise, there are project types that Windows VS can create that VS for Mac doesn't understand. This is what produces the error you see.
In my case, on Windows VS the solution contained a "web site" folder (e.g. globe icon). This was really just a folder with HTML files in it, but the solution defined it in a way that the Mac OS VS didn't understand. My solution was to fire up the solution in Windows, remove the html project, and add a Solution Folder (plus all the child folders and files). VS doesn't treat these Solution Folders as projects, and so on the Mac there was no problem opening the solution.
Some background: https://www.monodevelop.com/documentation/solutions-and-projects-explained/
I just can't find this setting in VS 2012, but it is described in the Visual Studio documentation. Is it not available for C# projects? Or where can I find it?
Extensions to Delete on Clean
The Clean option (Build menu) deletes files from the intermediate
directory where a project's configuration is built. Files with
extensions specified with this property will be deleted when Clean is
run or when you perform a rebuild. In addition to files of these
extensions in the intermediate directory, the build system will also
delete any known output of the build regardless of where it is located
(including intermediate outputs such as .obj files). Note that you can
specify wildcard characters.
This is specifically for C++ projects. The topic you linked to is located in the parent topic "Property Pages (C++)" which itself is part of "Visual C++ -> Creating and Managing Visual C++ Projects".
I have a VS2003 solution with 21 ASP.NET 1.1 projects in it. My goal is to eventually migrate them to 2.0 and then 4.0. There are mainly internal admin apps for different departments.
I want to create a multi-project solution now in VS2010 and migrate/re-code these one at a time in ASP.NET 4.0 Web Forms in VS2010. There will be some artifacts common to all projects such as CSS, scripts and images. Could the use of Resources help with the common files and would it be possible to have a single master page for all projects?
What are the best options for creating a multi-project solution here?
From what I understand, your goal is to share resources like CSS, JS files across projects. One way to do it would be to use linked files in Visual Studio. We do it extensively in one of our solutions where we share many class files and signing keys acorss projects. Linking files basically involves putting the files in one project in the solution and then linking to them from other projects of the solution.
You have to be a little careful though during deployment of projects containing linked files as linking the file does not physically copy the file to the destination project. So even if your project has a css folder, the linked file shown under that folder in VS is not physically there in the directory structure on the disk . If you link classes, the dll for the project that has the linked class file will include the linked class, but for resource files like css, JS and common masterpage, they will not be copied over when you deploy. You can leverage build scripts or some simple batch files to handle those issues. This should solve your problem.
Why not just convert them directly to .NET 4.0?
Beware when you move them to .NET 2.0 that the default project type in Visual Studio 2005 changed from the type of project you're used to in VS2003 to "web site" projects. But with Visual Studio 2010, you've got the same Web Application Project you're accustomed to, so why not just go there directly?
Also, be aware that VS2010 can target .NET 2.0 applications, so there's really no reason to stop there.
I've got a legacy solution with multiple project references.
Two of those projects are deployed independently, and both reference the other projects.
Currently the versioning is purely manual, but I'd like to automate the process (of updating the version number of AssemblyInfo.cs).
We're using Visual Studio 2010, SVN, and TeamCity, and already have a proven way of updating the version numbers for other solutions. However, those solutions only have one version number to consider, whilst this solution have to.
One way could be to update the two important, i.e. the reason for deployment, numbers automatically, and update the others manually.
Try : Versioning Controlled Build
Command line-utility supports VC++ 6.0 DSW files as well as VS2002/2003/2005/2008 SLN files. It shares configuration settings with the add-in version, but user can override these settings with appropriate startup switches. Please check CommandLine.txt file included in the setup for a brief description and list of startup switches.
During command-line utility setup, corresponding menu with two items are added to Programs menu. "AutoVer" entry starts the command-line utility with /g switch, opening the same GUI as the add-in does.