I have an ASP.NET Core app that will be using some class library projects e.g. domain, repositories, etc.
These class libraries will also be used in another cloud app that runs as a worker role which is why I want to keep them separate and their development should follow its own course and not necessarily depend on the ASP.NET Core app.
With that said, the ASP.NET Core project should be aware of any changes made to the class library projects which is why I want to link them to the solution for the ASP.NET project.
What's the best way to structure these project folders? Currently my folder structure is as follows:
My Projects Folder
--- MyAspNetCoreProject (Has its own solution)
--- MyBackendProject (Has its own solution which contains the following projects)
----- DomainProject
----- RepositoriesProject
When I try to "Add Existing Project" to link my backend projects to my ASP.NET Core project, I get the following message:
The project that you are attempting to add to source control may cause
other source control users to have difficulty opening this solution or
getting newer versions of it. To avoid this problem, add the project
from a location below the binding root of the other source controlled
projects in the solution.
You'll need to move the referenced project under the same solution. If you do want separate solutions you can't link as a project -- before .NET Core you could link the assembly(s) instead.
One problem of trying to link projects under other solutions is that other users may not have a copy of all the necessary solutions and may be installed in different locations from other users. The solution needs to keep track of where the assemblies are built.
If you build the library as a NuGet package then linking the reference is easy.
Your options become
Move all projects under the same solution
Keep separate solutions and publish your library as a (private) NuGet package
I have a Visual Studio project which uses a library (both written in C). Often I make a change to the library as well as the project. Each time I make a change to the library I click on the build button then go back to the project and build that.
What I would like to do is specify something such that when I build my project it checks the library, finds that it needs to be built, build the library then continue to build my project.
Is there a way?
In Solution Explorer, right click on the solution. Select Properties then Project Dependencies. Use the dropdown under Projects and select the project you are building. That will bring up a list of all projects in the solution. Put a check mark on each project that depends on the project you are building. This assumes, of course, that your libraries are also projects in your solution.
We are moving from Eclipse to Android Studio and we have a lot of libraries with resources developed for us.
In eclipse we had all this libraries in a directory and import in each workspace we use. It was a really mess, because some developers don't always work with android, so when they need, they had to update a lot of libraries, download new ones and configure everything.
When we moved to Android Studio, I mirrored the some configuration, adding the libraries into each project as symlinks to the real library project.
But, Android Studio has gradle and aar, so I discovered some ways to improve the way we manage our dependencies. After some reading, I find two ways that I thought is the best:
1-Copying each aar generated from our libraries and adding them to the lib folder in each project
2-Creating a server with Nexus to generate our dependencies.
I would like to know each of the two is the best, or if exists a better way.
Thanks in advance.
I have two projects that use shared source files. How can I organize the building process so that when I run one of the projects, Xcode builds both of them, making sure that both projects can still compile with the changes in the shared files?
The answer is to change Schemes for both projects, going to Build section there and adding projects, so that Build section for each project's Scheme has both projects.
In Eclipse, I have a workspace that contains all of my projects. Each project builds and compiles separately. A project does not interact with another project.
How does this relate to Visual Studio and Projects/Solutions there?
A VS project is it's own entity. It will build and compile by itself. A Solution is just a way to contain multiple projects. The projects don't necessarily need the other projects to compile (though, they can depend on the other projects).
This just lets you conceptually group projects together into one Big Project. For instance, you can have a separate testing project. It depends on the code from the actual project, and should be kept together with the actual project, but it does not need to be in the same exe/dll.
Each VS project builds a single EXE or DLL. The solution is just a collection of related projects.
So VS project:Eclipse project::VS solution:Eclipse workspace.
Another way to look at it is, a solution is a container for projects. For most of my work , I create each tier as a project within a solution so my tree looks like:
My Web App or Win App
Presentation Layer
files...
Business Layer
files...
Data Access
files
Your mileage may vary
#Thomas Owens:
Yes, some (most?) people using Eclipse have more than one workspace. It's what surprised me the most when I first started using Eclipse, so I'm replying here to make this comment more visible.
The thing that may be throwing you off is the following:
In VS2003, everything had a Project file and a Solution file. If you had a Solution with one Project, you could open the Solution and see the one Project. If you opened the Project, it would try and create a new Solution file to contain the Project. But web projects and Winform projects all had Projects and Solutions.
In VS2005 this changed a bit - by default now, Web projects no longer had Project files. They had received feedback from some web developers that didn't like Project files - their take was that if a file is in the directory, it's part of the app. After VS2005 shipped, they got more feedback from developers who did like the Project file notion, so they patched it back in. This is "Web Site" versus "Web Application" in VS2005 (and I can't remember which is which now).
In addition, in VS2005, if you have a Solution open with only one Project, you won't see in the Solution Explorer that there's even a Solution at all, you'll only see the Project (as if it was not in a Solution). Only after adding the second Project will you see that there's a Solution containing them both.
So basically you were on the right track - Solutions and Projects work the same in Visual Studio as they did in Eclipse, it's just some quirks that make things confusing.
A Solution has 0 or many Projects...
There are way too many kinds of web projects in Visual Studio 2008. There are Web Site Projects vs. Web Application Projects and they limit you in different ways. It's a good example of Microsoft providing too many choices instead of focusing on one strong solution. Even within the Web site Project option, there are at least 3 different ways to compile your application.
I found that not always seeing the solution in the Solution Explorer to be irritating. There is a setting in Options->Projects and Solutions->General called "Always Show Solution" which was handy.