I don't know if there's a way to achieve this, but I have a solution with its references on a single form page (made with ext.net, by the way) and wanted to use it as a reference to another project.
Is this possible?
Edit:
I think it was a poor question afterall. I have a solution with 3 different projects (web, entity and bals) and it's all good there. They all work together for a single form page. Now, I want all of that stuff to be inside another project, which is inside another solution, and call that page with its references from this other solution I'm trying to get it in.
To call an object (or a form) from your original solution in your new solution, you need to add references to Web, Entity and Bals.
There's 2 way to add a reference. You can add a reference to the compiled DLL / EXE or, if you have the source project, you can include the project in your solution (File -> Add -> Add Existing Project) and then add reference to that project.
If I understand your question, you would like to link an entire Solution instead of each projects individually. This can be done by changing the Add Existing Project filter from All Projects Files to Solution Files. This will allow you to import every project from the given .sln file.
However, this is a one shot deal operation that will import the projects at a given time. If you add or remove a project from your original solution after you linked them, you will have to do the same in your new solution.
When adding a reference to a project, you can select another project within the same solution or you can select a compiled DLL. If you have a library project in one solution and an application project in another solution then your only choice is to build the library project and then reference the compiled DLL in the application solution.
That said, there's nothing to stop you adding the same project to multiple solutions. You can add the library project to the same solution as the application project without removing it from its current solution and then you can work on it at the same time as the application, including debugging both at the same time. The application project can then reference the library project instead of the compiled DLL.
Related
I have an existing .net 3.1 functions app that I'm trying to add another project to. The current structure shows
Next I right click on the topmost directory (with the EIQT-765) and then select Add -> New Project. I select an xunit project template and add. I end up with this (noting that functions.test is at the root directory, and within the original
After a rebuild at the solution level (again, right click the topmost directory) I am able to add a simple assertion to the initially generated UnitTest1.cs file and right click on the file (in either place it shows in solution explorer) and run the test fine.
When I add some real test stuff that needs to use classes from the app I get a lot of "type or namespace not found errors"
As a freshman .net developer I've solved this in the past with adding a reference to the real project from the test project. I did the same here, Right click on the topmost functions.test folder -> Add -> Reference -> Select the real project.
Not sure if it's relevant, but the test project now has a mono_crash.[string].json file, which doesn't seem good :D.
Next I add the Xunit package to the functions.test project. However, the solution will no longer build unless I add the Xunit package to the real project.
Finally, after all this I have the following error when trying to rebuild the solution
Error CS0579: Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute (CS0579) which is where I'm currently stuck.
Is this the correct way to add a project to an existing one? Other projects I've worked on were set up as a solution first and I've never had this issue adding additional projects. What do I need to do to fix this?
This issue https://github.com/dotnet/core/issues/4837 leads me to believe I need to rearrange my project structure but I'm just not sure how to do this with a .net project.
This was the same issue in the github thread. In order to fix this I carefully moved things around until I had a structure like this
/FunctionsApp
functionsapp.sln
/FunctionsApp/Functions <-- all the original work went in here, including the .csproj
I then had to manually update the functionsapp.sln with the new path. Afterwards, I could follow the process of Add Project and Add Reference and my tests now run.
My question is about the necessary proximity of a dll to the project from which it was created. If you have two ASP.NET projects, and you copy the dll created by one of them, into the other project, (for example, putting it in a library folder), and then add a reference to that copy so it can be used, do the two projects need to run on the same server?
Many thanks!
Yes. You can definitely do this. You have to ensure that the referenced dll files are getting copied over. And as they are separate applications, you can easily deploy them on separate servers. Though I am not entirely sure why do you need to add a reference of ASP.NET project to another ASP.NET project. You might be able to achieve sharing of code by creating separate class library project and referring that.
We have a lot of websites with common functionality developed by 3 persons, in the business logic we use a common library project (in a shared directory) so we all use the same functions. This way the corrections and improvements are shared for the following projects or when we recompile an existing project. We have a class for some UI common functions too (loading a ListControl with x data and so)
The problem is with some web parts like CSS, Javascripts, Common Pages (login, configuration, customer management), those we don't know exactly how we can centralize them so we have those parts in the shared project so we don't have to copy paste corrections/improvements manually to the other websites each time...
Example of current website structure:
-MyWebSite1
-Styles.css
-Scripts.js
-Login.aspx
-Funx.cs (Functions specific to this site)
-Consx.cs (Session and other variables specific to this site)
-CommonProject (In a network shared directory)
-FunBusiness.cs
-FunWebUI.cs
-ConsBusiness.cs
-ConsWEB.cs
Is there a way of doing this?
For now the closest we have come to solving this problem is following this article for the Javascript part:
http://msdn.microsoft.com/en-us/library/bb398930(v=vs.100).aspx
We are now investigating using only one reference to a js file and including the other javascript references dinamically and the common CSS and MasterPages parts...
Maybe you can add those common references files as Linked File in Visual Studio. In this way you can maintain one file, while kept in a different location.
From Microsoft:
Link file leaves the file in its current location and maintains a link to the file from your current project.
Another solution would be to create a copy script before compile in Visual Studio. Reference over here.
We're a small team starting to use TortiseSVN to manage our web projects.
I was just wondering what is the best way to manage web projects into Subversion.
As you know a web solution consists of the .sln file as well as all the .aspx files.
Well we noticed when we right click the solution and we select "Add selected projects to subversion". It prompts me to tell it where to store the .sln file. So I give it some path like svn://serverName/CIS/MyWebSiteProject. Cool it just placed the .sln file...so I thought to myself how is it going to store the .aspx files as well.
Within a second I got a second prompt, I thought cool it is prompting me for the .aspx pages. So I tried giving it the path svn://serverName/CIS/MyWebSiteProject/ASPX_Files, but it comes back with an error stating I cannot place this folder within this path. I actually have to go outside of the folder MyWebSiteProject.
Not good cause now I have 2 folders one with the .sln folder and the other with all the .aspx pages and these folders are sitting on:
(sln file):
svn://serverName/CIS/MyWebSiteProject
(aspx files):
svn://serverName/cis/myWebSitePages
This really is not ideal cause I am sitting on the root of CIS with 2 folders for really one solution. Now when I try to check the project out I have to check both folders out.
What makes this even worse is when I do check them out I try to open the .sln file and I get an error that it cannot find the corresponding .aspx files. This seems like too much work, is there an easier way or a recommended way of using tortisesvn/subversion with asp.net web projects ?
While I am sure you have TortoiseSVN installed, it sounds like you are using Ahnk or some other VS SCC plugin to add from within VS.
I would suggest not using the plugin to initally add the solution to SVN, but to use TortoiseSVN in Windows Explorer for your initial check in. This will add your solution directory in its original state.
From that point on, you should be able to use the SCC plugin from within VS without trouble.
EDIT
Ok, after your commment I realize that I was not fully understanding the problem.
If you are dealing with a single project, after you create your solution and project, select the solution in Solution Explorer, go to 'file>save solution as' and save the solution inside the directory where your project file is.
Close the solution and go out to Explorer and use Tortoise to add the directory to SVN. If you have multiple projects/sites, just pick one to hold the solution.
Does that make sense? and from that point you should have no problems with ahnk
The key to successfully using Visual Studio with any source control is to put the solution file in the same path as the rest of the project files.
Usually, I will do something like the following:
\Project\Project.sln
\Project\MainWebSite\*.* <-- All web site files (including .??proj here).
\Project\Library\*.*
Then, I manually put \Project\*.* into source control.
Other options exist, as for my recent projects, I have been using:
\Project\SolutionFiles\Project.sln
\Project\MainWebSite\*.*
\Project\Library\*.*
Again, I manually put \Project\*.* into source control.
I generally find that it is better to set up the repositories for my solutions and projects from within Tortoise SVN. Then use whatever VS plugin that you care for to manage the commits of your pages etc. This gives you a little more control and allows you to get your setup correct from the start.
Let's say you have a solution with two website projects, Website A and Website B. Now inside Website A's App_Code folder, there is a Class X defined in a ClassX.cs file. What do you do if Website B also needs access to ClassX.cs?
Is there any way to share this file across App_Code folders? Assume that moving the file to a common library is out of the question.
Please please don't use these unholy website projects. Use Web Application projects instead, pack your shared classes into a library project and reference it from all your Web Applications.
Pack your shared classes into a Library (a DLL) and from each site right-click on add reference and select the library that you have created.
With the restriction of "Assume that moving the file to a common library is out of the question." the only way you could do this is to use NTFS junction points to essentially create a symlink to have the same .cs file in both folders.
This is a terrible option though (for versioning reasons)...moving it to a common library is the best option.
Here's the Wikipedia entry on NTFS junction points
http://en.wikipedia.org/wiki/NTFS_junction_point
and here's a tool for creating them
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I don't believe that there is a way without moving ClassX into a new code library project. .NET requires all an assembly's dependencies to exist in the same folder as the assembly itself, or in the GAC, to be automatically detected.
You could try loading the assembly manually via the Reflection classes, although it's a bit hacky.
The best solution, if you have the time available and the inclination to undertake it, would be to go with JRoppert's solution of moving it to a web application project. You could then use web references (which work about as nicely as regular references inside VS) to refer to ClassX.
HTH