How I add a .shproj to my Visual Studio solution and reference it from other projects?
I know that Visual Studio 2013 Update 2 added a new project type for "Shared Code." This type of project does not produce a dll itself. Instead the files from the Shared project are included as source files in the assemblies that reference it.
I know it exists because I have seen one in an open source project. However, looking through the project templates in Visual Studio I could not find a "Shared" project type.
Edit: According to the Visual Studio 2015 Preview documentation, VS 2015 adds templates for shared projects and a UI for managing the references, so the below should no longer be necessary after upgrading.
There does not seem to be a way to create one directly. It appears currently that Shared Code projects are automatically created when you create a Universal App project as shown in this introduction to creating a Universal App.
Therefore, to create one in your solution: Add a new project type "Blank App (Universal App)." Delete the Windows 8 and Windows Phone projects it created leaving only the Shared project.
Check out the Shared Project Reference Manager extension.
Note: make sure you have VS2013 update 2 or above for this to work.
An alternative to vossad01's approach is to create a shared code project, then open up the .csproj file and see what the project looks like in the .csproj. Visual Studio's csproj files are simply XML files so you can open, copy, and paste the shared code project into your own csproj.
Related
I have an ASP.NET MVC project with one solution and 52 projects in the same solution. As you know, It takes long time to build whole solution. So I decided to unload some of the projects until there is some change or sprint task in the code in the unloaded project. However we are a team and use TFS version control and we need to use update unloaded assembly. So I have a build server that makes me sure whenever somebody starts to check-in (for example -> C:\bin in our network) the last version of all assembly can be found there.
I added C:\bin path as Reference Path to the UI Project (main project of the solution) of the solution and I expect when some projects is unloaded the reference comes to visual studio from the build server path (C:\bin) otherwise the reference of the project comes to Visual Studio from the nested project (not from build server).
But the reference can not be found when the project is unloaded:
And my Build server contains the assembly:
Finally I found a way (only in Visual Studio 2019) to unload projects and however use updated class library of unloaded projects. And thanks to Hooman Bahreini for his idea of using two separated solutions.
The way is that, there is a feature of Visual Studio 2019 that we can Save As Solution Filter which is in .slnf extensions. So I can unload some of my projects and check-in .slnf file via my source control (like tfs). So I have two solutions Now, one is .sln which is contains all of projects and the other one is .slnf which is unloaded some of projects in it.
The things can we do is that whenever I want to get my project I have to use .sln file and builds that and then close the file and then open the .slnf file (I'm sure that I have updated class library of unloaded projects) and do my task and check-in my changes.
I'm on a new PC and I wanted to do a Coding Project. I wanted to code a Console App that uses your Clipboard.
I searched on how to do that and got the answer that I should use System.Windows.Forms. But if I want to add a Project Reference, it doesn't show up the tab "Assemblies". I installed every version of .net core and framework. I just can't add a project reference. In the installation of VS I had not much Drive Space left, so I only checked the option .NET desktop development.
You have to Browse and include the file System.Windows.Forms.dll manually.
In my case, that file is in the following folder:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2
This question already has answers here:
What is the difference between a Shared Project and a Class Library in Visual Studio 2015?
(6 answers)
Closed 6 years ago.
What are the practical implications of adding a normal Project (WPF Application, Windows Forms Application, etc...) vs a Shared Project as a reference in Visual Studio 2015?
I know that Shared Projects are a rather new (since VS 2013) and presumably superior feature, so I would like to know all differences.
Could one difference be that files in the Shared Project can use code from projects where the Shared Project is added as a reference if all of those projects do have the code to be used?
This is not possible in a normal Project of course.
Also for some reason Visual Studio shows me far less suggestions if I do "Add -> New Item..." on a Shared Project.
As a sum up of differences found so far (take that with a grain of salt as I'm not an expert):
Shared Projects vs normal Projects (Class Library, WPF Application, Windows Forms Applications, etc...) added as a reference:
Files in Shared Projects can use code from projects where the Shared Project is added as a reference if all of those projects do have the code to be used.
Shared Projects do have less suggestions when "Add -> New Item..." as they are more generic.
Shared Projects are not compiled to .dll or .exe but added with source code to the project referencing them and therefore can be debugged step by step.
Project, assuming a class library, will be compiled and the dll will be referenced from the other project. Shared Projects are fancy way of file linking (or copy pasting the code file when compiling). This has benefits as in you can have access source code that is not only in shared project but also in the target project (as long it works for all referenced projects). But can also give conflicts if using this in an library that will be referenced in your target projecct too. I think you best can go for a normal class library and only use shared project if you are really sure you needed (was introduced to have better code sharing between your win8.1 and wp8.1 app)
I am building a Xamarin app in Visual Studio, but am having problems with the source control, which I think is because I don't have a nuget.config file.
Firstly, do I need one per solution or one for the whole project, or alternatively just on in the PCL etc.
Secondly (the main question), is it possible auto-generate these files based on the nugets you currently have installed? Also, when these are updated, is it possible to keep the nuget.config file up to date?
Update:
In Visual Studio the Manage NuGet packages for Solution option which was present in past versions is not displayed for my project, not sure if this is the software version or the projects configuration.
I have a DLL I need to deploy with my C# application. It's not currently included in the installation package when I hit "Publish" so how do I include it?
Would the process be any different if I had app.config and other files I wanted to deploy with my application?
If it's referenced it should be included automatically. I've deployed a couple of apps that require a 3rd party dll and they've published OK.
Is the dll referenced correctly in your project? That's the only thing I can think of at the moment that might be the problem, but if it wasn't your code wouldn't compile and/or link anyway.
To get the xls file to deploy all you need to do is add the file to the solution and then set the "Copy to Output Directory" property on the file.
I take it you are using Visual Studio?
If your using Visual Studio 2008 (I have no experience with Visual Studio 2005) under the Publish tab in your project properties click on the Application Files button. This will bring up a list of all dependencies assembalies required by your project. If you find that required dll is not being published by the Visual Studio publisher tool by default you can go into here and set the Publish Status of the offending dll to Include.
Sometimes in my more complicated projects, depending on the type of dependency, I have to go into this menu and force certain dll's to be included opposed to the default Prerequsite setting.
...but this is all under the assumption you have the assembly properly referenced in the required projects and everything is compiling fine.
Can't you add the dll as a resource to your installer project?