I have a "common" web template project in tfs. This web project is mainly for common layout and library framework that will be used for many other projects.
Every time I work on a new project, I always create a branch from the "common" template. With such structure, if there's new changes on the common framework, I can always merge the new changes to the "common" template.
The problem I face now is when I have multiple projects open and I try to run the project, it always run the project I first opened in VS. It think this could be due to the assemblyinfo.cs in the project. I tried to change the solution name and the project name but couldn't resolve the issue.
My VS version is 2012 Professional
I still couldn't find a suitable answer for this. What I had to do to get around is to set the virtual port on the web project.
Related
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
Our company is planning to start a large new WinForm project, it will be written in c#-4.0 using Visual Studio 2010.
This project will have many modules (Production, Accounting, Service and etc...) and each module with have lots of possible forms. So we are testing the idea of create multiple projects inside a single solution and have each module be it's own project rather then having a single very large project.
I created a test solution with two projects A and B, next I added each project as a reference to the other project, when adding one project as a reference to the other, I right clicked on Reference>Add Reference>Browsed to the other projects bin/Debug folder and added the other project's .exe as the reference. Next, using the other project as a namespace I was able to do things like form inheritance and opening forms or calling methods between my two test projects.
But I accidently clicked Clean Solution which cleaned the bin/Debug folder for my two projects, and all of my references between the two projects were broken.
What is a proper and reliable way to add permanently references between projects inside a single solution? I was thinking I could physically copy each project's .exe into the other projects bin, then add it as a reference. But that means I'll have to manually re-copy it every time the other project get's updated.
In every tutorial and HowTo site (like here) about WiX I read I should add reference to my other project, but when I select Add Reference I have nothing on Project list in Project tab. I try this on Visual Studio 2012, earlier with WiX 3.7 and now on 3.8.
If there is solution simply not using "Add Reference" function how can I build this other way? I'm a beginner so I don't really know how to use WiX without this feature, if I published my C# application in Publish Wizard I should add all produced files to Component Group with every file in <Component> tag?
It could be this simple...
In Visual Studio, Add Reference's Project tab only lists projects in the same solution. You just need to Add Project to the solution and go back to the Add Reference's dialog.
A solution is just a set of zero or more projects that can be built together. You can have a project in more than one solution. The only limitation is that if project B references project A (B is downstream of A), A should be in every solution that contains B. If the universe of projects is small, it is typical to have only one solution for them all. On the other hand, if one developer works only on upstream projects, that developer might find it easier to work with a solution that doesn't have downstream projects.
Setup projects tend to be downstream but note that they probably don't depend on library test projects.
[Stream is not the best technical term. The universe of connected projects is a directed acyclic graph.]
We recently migrated to TFS 2010, and have created a new Team Project. (The old one was created in 2005, and seems to be missing key metadata to allow full functionality in 2010). We've copied all our source, and have figured out how to copy our work items to the new team project, but we can't figure out how to migrate our build definitions.
Is there a way to do this, or will we have to re-create them manually?
Thanks!
[EDIT]
Jeff-thank you for the reply! After reading it, and more deeply considering my situation, I realize that my description (and probably my entire question) was flawed.
We originally upgraded our 2008 team project to 2010. It had previously been upgraded from 2005. Up to this point, we've been using CruiseControl.Net to manage our builds. One of our team noticed that our upgraded project was missing some key metadata, and theorized that stuff had not been added in the migration process, so he created a new 2010 team project and imported our source as a test. Now we have two 2010 team projects: the originally migrated one (that we're all using), and the "from-scratch" one.
In the meantime, I was experimenting with TFS Build on the originally migrated project. I created a dozen or so builds, and was refining them, but we haven't moved off of CC.Net yet.
The decision was made to start using the "from-scratch" project, so I was hoping to somehow copy the builds from one project to the other. I don't see a way to do that... there is no build proj file to copy (TFS seems to keep the build definitions internal in 2010).
Normally, when you upgrade to TFS 2010, any build definitions you previously had will be automatically upgraded with the associated Team Project. It sounds like, at least in your case, that your Team Project did not upgrade completely/correctly so you had to start over with a new Team Project.
To copy your build definition, you will need to:
Copy the TFSBuild.proj file(s) from your old Team Project to the new Team Project - under whatever version control folder makes sense.
Create a new TFS 2010 build and select the Upgrade Template (in the Process tab).
Set the Configuration Folder Path property to the location of the copied TFSBuild.proj file copied in step 1 above.
Fill in the remaining required settings.
Hope this helps.
There's been significant changes to how builds are done from TFS 2008 to TFS 2010. One of the reason's why it appears that 'stuff has not been added to the migration process' is because it just does not exist. Even upgrading from TFS 2005 to TFS 2008 had a bit desired in it's completeness.
Jeff provided some good guidance to use the Upgrade Template, this will actually call the tfsbuild.proj file that was carried over from TFS 2008.
As a good practice, you'll want to create a copy of the DefaultTemplate when a new build definition is created for a corresponding relationship. Do this while creating the build definition in the process part of setup. There is a detail expansion arrow that will allow you to create a new, which is a copy of the default, and name it whatever you like. Unless of course there will be absolutely no customization done to the build definition or all of the builds in that project will be following exactly the same steps. i.e.: dev_sso_ci (build definition) corresponds to dev_sso_ci.xaml in the BuildProcessTemplates folder.
Hope this helps too.
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.