I have two ASP.NET web projects and they share a lot of images and JavaScript files. I tried to create a shared project and linking it into both ASP.NET csproj files:
<Import Project="..\Shared\Shared.projitems" Label="Shared" />
But images inside the shared project are not found during debugging with IIS (Browsers "image not found" image is displayed). But Visual Studio recognized them and showing the image files in IntelliSense.
Any ideas?
You still can bundle resources with project and distribute it, but you nee to create nuget package.
create project
make nuget package
publish it to private feed (e.g. myget.org)
add reference to your feed from client projects
PS: Only content of folder 'Content' included in nuget package.
Apologies for the speculative answer, but hopefully this will help someone;
This is a struggle I'm currently facing too (which is concerning, as nearly two years have passed with barely a mention).
I have also had to manually add the Import line to each solution as it appears you have.
I think the issue is with the inbuilt debugger not knowing how to serve the files properly. If you deploy the compiled solution to any instance of IIS it appears to work correctly.
I am experimenting with the inbuilt debugger to see if I can get it to work, but am quite confident I'll have to use a local IIS instance moving forward.
Shared projects provide invaluable functionality, so it's a shame it's still not natively supported.
At the end of the day your images have to actually be somewhere, you can't just reference them from another project. It would work if this other project was hosted in IIS, given a domain, and you referenced the images from this domain. Perhaps call it your CDN.
When you reference a project to get at classes etc, the project is bundled up in to a dll and packaged along with the main project. Images, js files etc can't be bundled in to a dll, and will not be copied across to your project.
Related
I have a big solution with 30 projects of which 2 are web projects (MVC and WebAPI) with a bunch of background class library projects.
I have visual studio set up to host the web projects in IIS.
If I do a clean build, followed by a full build of the entire solution, then accessing both projects via a browser works fine. (they are in diff folders and hosted on diff 'domains' in iis)
If I make NO code changes, simply rebuild one of the 2 web projects, the OTHER one stops working.
To be clear, rebuilding the WebAPI project causes the MVC project to have errors. And vice versa.
The error I get is saying that System.Web.Http.Formatter is not found. The detail says that the located assembly version is different from the reference version. Checking the bin folder shows that that is not the case.
Make sure that all the solution's resources are up to date. If you use Nuget, update all packages in all projects (back up first!). It sounds like you have a version mismatch, where functionality is missing in DLLs copied to the output directory for the solution. It may involve changing some entries in the Web.config of each project, but without access to the code, it's hard to know for sure.
Report back once you've updated every library, and made sure the versions match across all projects in the solution.
In addition to Apache's and Steve's suggestions, I'd also recommend deleting the files in your Temporary ASP.NET Files directory. If you're curious here's a good write-up of what the contents of that folder are for.
I have a solution, Asp.Net web application and inside the solution I have two projects. One contains VB code that handles the UI. forms etc. and the other one C# that basically uses Linq-to-Entity to handle my data. When I run the project from my local computer it works good. Now, to publish, I notice only when the UI Project is selected, the publish option is enabled. Why is that? If I publish this, would the other project not be published? Another question, I have XML files created in app_data folder, when I publish it, will I be able to access it?
Publishing only applies to web projects. If you've included a reference to the other project in your web project, it will be compiled and the DLL will be published along with your web project. Your XML files should be published along with your web project, if they aren't check their properties and make sure they are set to be published with the project (build action set to Content and Copy Always or Copy if newer is selected).
You have two projects inside your solution. One is web project and the next will be a Class Library project. All the codes related to Entity framework, LINQ queries, Database transactions, etc should be in the class library project. while building the class library it will automatically generate the DLL files. then you need only add a reference to the web project file. Then you will get all the classes, methods etc from the class library. there is no need for publishing the class library project. Because you have add the dll reference to your webproject. all the code file inside your App_Code folder shuold be converted to dll while publishing the web project. so dont worry about the files inside the App_code folder data.
Thank you
You dont need to publish reference projects individually or even the whole solution. It works simply by referencing the dll of your other project.
Both projects need to be compiled if not already
If your UI project has reference to dll from data layer project it will be published with your UI project.
You can publish it locally in another folder and test using iis express or your local iis and then publish it online with database. Update connection string and it should work if setup correct.
So I have a solution which contains 4 projects, a "Core" Project which is the actual application (as a class library), and 3 wrapper projects, "Console", "WinForm" and "Service" which basically wraps a Facade class in the core class and contains various settings to handle different logging strategies for each different application (Console/Trace/File) and launch the application as either a Console, WinForms or Service, depending on how the customer wishes to deploy the application.
In the Core project I have 3 resource files which contain simple template views for the Nancy web framework. However the way Nancy looks for these views are on the current path. Since the files in the Core project aren't on the current path for any of the 3 other projects I need a simple way to access these files across projects.
Somewhat naively I thought this was where the concept of a "Solution" came in, to handle dependencies between projects. However by searching the Internet, much to my surprise, it appears there is no elegant way to do this. The only two solutions I've been able to find involves copying the files to a scratch/temporary or directory in the solution, and copying them to the respective needed directories later, as post build actions, and Adding an item manually using "Add as Link". Now while both these solutions technically work, the first leaves (possibly out-of-date) build artefacts lying about where they don't really belong (IMHO), and the second is tedious, time-consuming and prone to human error (because you can't just link to a directory).
Are these really my only two options, or is there some third, totally obvious way I've just missed because I'm new to Visual Studio?
You could use a custom IRootPathProvider in Nancy, if the only things you need are Nancy specific.
The other option is to link a folder - you can do this, but it involves manually hacking on the csproj file, there's a few questions on here about it, including this one:
Visual Studio Linked Files Directory Structure
Nuget is a package management system, that I have used to share artifacts between projects as dependencies. You could include libraries available via nuget.org or have your own nuget packages defined.
Teamcity has got good support for generating nuget packages with every build and can serve as a Nuget server.
Here is a reference to include files into a nuget package.
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.
We are using TFS and VS 2010.
I have been working on a project that is using TFS as source control.
I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.
When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.
What did I do wrong here? How can I include those referenced DLLs in source control.
Do I need to add all these dlls to my project before referencing them? when I referenced them, I just browsed to where they were on my file system.
I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.
Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.
The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.
I created a "ThirdPartyDLL" folder in my project folder in which I copied all the extra DLLs into it. I then went into source explorer and added those DLLs into the team foundation server so I could be sure I'm using the correct versions of the DLLS for specific versions of my application (and so everyone else is on the exact same page as I am).
View - other windows - Source coontrol explorer
Right click project folder - add items to folder
You won't be able to select a specific folder with DLLs in it, but instead you can select the individual DLL files within the folder. You will then see the "ThirdPartyDLL" folder appear in that window.
Once this is done, those dlls are in the team foundation source control. Whenever a dev checks in, they will get the most current version of the DLLs.
Don't forget to remove the old references in your app and change them to your thirdpartydll folder.
I used to copy the DLLs into the bin folder but the issue I ran into was when the DLLs got upgraded. Initially when my project was small it wasn't a big deal. Now that I have multiple DLLs and applications that I created it became very difficult to maintain consistent versions of DLLs outside my project. My best example is the licensing dll I purchased. When this got upgraded all applications and libraries needed to be on the same version. If I forgot one then I had weird issues or the application just stopped working. Now that I have everything in one folder, I make the change once and everything is upgraded.
Hope this helps.
Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.
I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.
My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.
Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.