We are facing a very weird situation using Visual Studio 2005:
There is a Web Site project we do have, and VS when compiling the project automagically adds some undesired references, like 'System.Data.Oracle' (we don't use Oracle at all, and never did) and things from asp.net 3.5 (the project is 2.0, we don't use in it anything related to the new version).
As a consequence of this, when putting the published site into the production server (configured for 2.0, without these strange dlls), the site doesn't work. Even if we remove these dependencies from Web.config file.
Have any of you ever seen something like this happening with your VS05?
Note: the bin folder doesn't have these dlls.
Save your sanity and stop using Web Site Projects. They were an abomination from the get go.
The conversion to Web Application projects is well worth the effort.
Are you using Visual Studio 2005 SP1? You should be. There are bug fixes in addition to the fact they added Web Application Projects back.
VS2005 isn't inventing these references. Something in your web site is using them.
Are you precompiling the site prior to deploying it?
We could resolve it!
The web site project references a project.
This project had all these references, and the web site used them.. Removing the undesired references resulted successful ;)
Related
I am having some problems deploying an app I created to IIS on Amazon AWS. I have basically taken a sabbatical from development and haven't deployed an app in over a year.
The app has been transferred across fine and runs to the point of causing errors and displaying that frameworks are missing etc. I solved this in the past by:
Changing what version of .NET was being used on the server
Including all DLLs when the programme actually transferred (not what it does by default)
For the life of me, I cannot remember how to include all DLLs when deploying the programme so those can be relied on instead of the system's frameworks. Can someone please remind me?
You can do Right Click on Project and select Add Deployable Dependencies from the context menu
As of MVC4, all necessary assemblies to run an MVC application are
automatically added to the bin directory, and any MVC4 application is
bin-deployable (means you can run it in a server without explicitly
installing MVC) . For this reason, the Include Deployable Assemblies
dialog has been removed from Visual Studio 2012
More here: https://stackoverflow.com/a/10441585/1241400
Are you by any chance talking about Bin Deploying MVC? It's kind of a pain to do, considering you need to remember to make sure those dependencies are in your bin folder any time you either move the application around, put it on a new server, etc.
What errors is your displaying? I think you'd probably be better off resolving those, if possible. Windows has gotten much friendlier with installing updates in the past few years.
I've a solution with several .dll projects, an Asp.NET MVC3 Razor project and an Cloud project.
If I try to compile the solution with the Cloud project loaded, VS2010 gets stuck in "Buil started".
I have to forcefully close VS2010 killing the process and restart. Then the compiling works good once, the next time it will get stuck again.
If I unload the project and set the mvc project as start-up, everything works (but azure of course).
What could be the problem?
Cheers.
Was it by any chance an ASP.NET MVC project to which you added a CloudService project later on or did you start off with a CloudService from the very beginning?
I was in the former situation and I had no end of problems, like not being able to open property pages or deploying the application. It's not quite your issue, but the following article might help:
http://tomkrueger.wordpress.com/2010/07/27/azure-deployment-issue-after-upgrading-to-visual-studio-2010-and-net-4-0/
As I say, my problems started because I actually added an Azure project to an existing ASP.NET MVC solution and there were some unnecessary settings left over in the web.csproj file.
All I had to do was open web.csproj in notepad and remove all occurrences of the <PlatformTarget> element.
My MVC prjoject was x86 and of course Azure works on x64 only. Even though I had the platform target set up as AnyCPU somehow Azure couldn't quite get along with it.
Maybe cleaning up your project files helps as well.
I recently upgraded from VS 2003 where I was working on a ASP.NET 2.0 website to VS 2010 where I have migrated to ASP.NET 4.0. So far it has been a big headache to get my site compiling with the new version. One problem was that my aspx.cs pages could not find the shared code libraries in my project. I solved this by moving my shared code to the App_Code folder (if there's a different/better way to do it please let me know).
Another issue that I am finding confusing is with pre-compilation. With VS 2003 I could click the build project button and it would precompile my site into a myweb.dll and myweb.pdb files. Now I'm having trouble doing the same in VS 2010. When I build the site in VS 2010 the dll is not created. I did manage to find an option to "Publish" the site which takes forever (like 2 minutes) and involves duplicating the site to another folder. This would have been acceptable but instead of making the single DLL file, it makes a bunch of files: App_code.compiled, app_code.dll, App_code.pdb, App_global.asax.compiled, App_global.asax.dll, App_global.asax.pdb, App_Web_lrpcway1.dll, App_Web_lrpcway1.compiled, App_Web_lrpcway1.pdb.
The application works - I can deploy it with all these files. However, I'd really like someone to explain what are the extra files and if there is a better way how to do it.
Thanks
This is the difference between a website and a web application.
You can convert your website to a web application to have it
behave more like you are used to.
The files in appCode are compiled when required to run and thus
does not provide dll.s in the bin/debug folder, but they should
be created when the application actually runs (but it is not
put in the same location).
Here is a nice write up about it Link
You can use the ASP.NET Merge Tool to combine all of the little DLLs into one big one.
http://msdn.microsoft.com/en-us/library/bb397866.aspx
In the very near future I'll be migrating some web applications from VS2003 projects to VS2005 projects.
What should I watch out for?
Anyone done this in the past and have it go bad?
How much time should I expect it will take to migrate a project?
I know this is more than one question, but please provide your experiences with anything relating to migrating projects from VS2003 to VS2005.
Thank-you
EDIT
The types of projects I will be migrating are Web Applications written in Visual Basic.
Do you absolutely have to go to VS2005 rather than straight to VS2008?
Even though Web Application Projects were implemented for VS2005, first with an add-on, and later with a service pack, IIRC, upgrading VS2003 web projects was extremely flaky.
We had a dozen or so production web sites (all written in VB.NET) running ASP.NET 1.1, and wanted to move forward... it proved a complete nightmare (even with Web Application Projects installed), and we gave up since we didn't have the resource available to persevere.
Then VS2008 came along, and I had another go.
Bingo, no problem at all. The project upgrade wizard just ran, there were a few trivial code fixes, and it just worked.
Straight from VS2003 to VS2008 in about an hour. All the sites ran off the same code base, and upgrading was as simple as copying over the folder, and changing the IIS management tool so that it specified ASP.NET 2.0.
I imagine you can guess what my recommendation would be!!
Be aware of the differences between a Web Site Project and a Web Application Project.
I really would go straight to VS2008. You can 'throttle back' your project so that it 'only' uses .NET 2.0, if that's a requirement.
As far as what to watch out for - ASP.NET 1.1 and ASP.NET 2.0 are very different creatures, I've discovered. ASP.NET 1.1 let you put objects on a web page much the way you would drop buttons, labels and text boxes on a desktop forms application. This is no longer true in 2.0. I had a LOT of self-education coming to me when I started working on my current project in that I really had to learn how to lay out presentation-layer stuff with ASP tags (divs, style sheets, etc). The code-behind was still the same - handled better in fact. This all depends on what kind of web projects you're migrating and how they were written in the first place.
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.