I've been asked to make some changes to an old ASP site, and I've been editing individual ASP files in VS (I don't have the original project file). However, I'm finding that none of my favorite ReSharper actions (like Selection Extend/Shrink) are firing while editing that individual ASP file. I know this feature is supported in ASP, and they work when I'm editing C# files as part of a larger project.
Do these features only work when the ASP file is opened as part of an ASP.NET project? Is there something else incorrectly configured?
I'm using R# 7.1.3 C# Edition and VS 2012 Ultimate (11.0.61219.00). Thanks!
Update 1
I just tested opening a C# file from VS without opening the C# Project file. I was NOT able to use the ReSharper features. Perhaps a project file truly is required?
ReSharper doesn't know anything about Classic ASP, which means there's a lot of functionality it just can't implement. For example, "extend selection" - extend to what? Because it doesn't know what the file format is, it has no way of knowing what code construct the selection should be extended to.
In a similar vein, it can't offer full functionality for known file types, such as C#, unless they're in a project, because the project gives it so much context. For example, all the types you're using are defined in assemblies that are referenced in the project, so without a project, you don't get the assemblies, you don't get any known types, so you don't get code completion.
Related
I have a website developed in old technologies like ASP, ActiveX, COM and some other legacy technologies. I want to re write the application in ASP.Net MVC, I'm not sure how to remove those ActiveX and COM and which is the alternate option to use for those components. Another pain point is i do not have the source code of ActiveX and COM dlls, So we want to re-write the application as earliest possible, can anyone suggest the possible option that how i can start migration.
Is it possible that i can replace the ActiveX components one by one ant test the functionality and re-write another Activex component?
Also can somebody share the materials/links to best understand ACtivex and COM ?
I have literally had to do exactly the same thing.
I want to answer your question properly:
Is it possible that i can replace the ActiveX components one by one ant test the functionality and re-write another Activex component?
You could but that sounds unnecessary.
Also can somebody share the materials/links to best understand ACtivex and COM ?
Create a blank ASP project
Set the target framework to be whatever (.net 2.0?)
Copy and paste all your files into this project, so that the web.config is in the root.
Now, to get your COM and Activex elements, right click the "References" folder and add reference. Goto "Extensions" and you should see COM modules there. You need at least the Microsoft ActiveX etc etc scripts. I imagine you have some lines like CreateObject('ADODB.CONNECTION'). You can search using the object explorer as to which COM modules contain which objects.
Tick them to include them, then build.
It might take a bit of fiddling, and there were some objects I couldn't find, and also some I had to download an install manually (but then after that they appeared in the extensions menu, so it was straightforward).
I managed to get an ASP2 project working in Visual Studio 2015 this way.
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I've read a lot of discussions about web site vs web applications in asp.net
The way we work in my team (10 programmers), we use the project type "web site", and for our dev environment, we just copy the source code (aspx + .cs) to the server. This way, all the programmers can be doing changes at the same time.. and the server does the build dynamically. .....(for the prod environment, they build the application)
Now, I'm starting a new project, and I decided to use web application (the main reason was the web config transform option).. I soon realized that (as far as I know) it forces you to do a build/publish of the web app to the server with every change... which is not a big problem if I'm the only one working on this project...
But, now I'm wondering, what's going to happen if more programmers needs to work on this new project at the same time?
Any advise or similar situation?
EDIT
we're using Visual Source Safe... but only for keeping track of the older versions (not for builds)... I'm familiar with Subversion... but.. unfortunately, I don't take the decision on what we should use.. and I don't think they're willing to change
Thanks everyone for your answers...
Anytime I hear the, this isn't a big problem as long as. . . . immediately tells me, that I should assume that it will be a problem. In short, go with what you know. If you are familiar with using the ASP.NET website, then I would use that. Your development practices are already focused around handling that.
This is the same model that I used when doing classic ASP when I first started programming at a company. This model works, although I would strongly suggest getting source control too. That being said, here is what I would do long term:
Source control
Develop locally
Get a continous build process going (cruise control is a free one).
Have one person push everyone's changes to the development server, once everyone agrees that all the changes are compatible with each other. (normally this is done by making sure the build server can compile everything).
If you choose to use web application and add more programmers on the project, I recommend using source control. Git and Subversion are very popular. In Git, for example, you can see who commits what.
Of course, I would use source control from the get-go, whether you're on your own or collaborating with a group.
As #edmastermind29 said source control is really the #1 thing to keep that straight if you are having more then 1 developer.
It really depends on your development process. Most shops do some type of continuous integration and have unit tests running and have some sort of automated build process.
I have found that using a web application project is really the best for all the "best practice" types of things.
Check out this link for some guidance.
It really depends on how your team works, and how your environment is configured. Regardless though, you need to have some sort of source control system in place to ensure that your not overwriting each other's changes. If you don't already have a source control system in place, stop now and get one immediately.
Depending on which source control system you choose, you will at least have the basic checkin/checkout features that serve as a library for your code base; meaning if I have a file checked out you can't touch it until I've checked it back in.
If you choose a more feature-rich source control system, you should be able to take advantage of features like branching and shelving, which will allow your team to work on the same files simultaneously, and merge the changes when the files are checked in.
While your question is about web sites vs. web applications, the answer is source control. With a good source control system in place, your question becomes more or less irrelevant, aside from needing to coordinate builds with a web application.
I figure this is a straight forward question, and I think there is a good chance the answer is "yes" (while mixed-language projects are generally not possible, it seems to me that the View Engine gets special treatment). I know I could also try this out pretty easily myself, but for the record, and to save myself some time, I'd like to know if this combination is possible (I've not used ASP.NET MVC or Razor myself yet, I'm considering options for a new project at work).
Edit: I am particularly interested in whether this combination is possible within a single project. Or more specifically whether there are any feature losses using this combination (even if the two project setup is the way to go).
You can definitely mix a C# Razor code with F# controllers. It may be possible to do this in a single project (by modifying the web project to use F#). An easier alternative is to create a standard C# Razor Web project and a separate F# project (containing model and controller code).
I created a Visual Studio template that allows you to do exactly this.
Unfortunatelly, the template is not yet available on Visual Studio Gallery (so you cannot see it from "Online Templates" tab in "New Project" dialog). There is some issue with their upload mechanism, that I'm trying to resolve, so it should hopefully appear there soon. There are also several ASP.NET MVC templates by Daniel Mohl on Visual Studio Gallery, but I'm not sure if any of them uses Razor.
I'm currently evaluating tool options for Voice XML development. I'm currently seeing if existing web development tools will work, since the model is quite similar (markup sent to browser client, ECMAScript in the browser, pages on web servers, etc.). I know I can use aspx pages to generate non-html markup, but I'm wondering if there is a way to get the IntelliSense to work the same way it does if you were editing an XML file in Visual Studio?
You can add intelligence support for any kind of xml document by adding it's schema definition to XML\Schemas folder of VisualStudio.
if you are asking of combining VoiceXML and ASPX markups together in an .aspx files i think it would not be possible in that way. i think it requires a new ViewEngine (for example something like Razor is doing that by combining Razor-Markups & HTML)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
ASP.NET: Web Site or Web Application?
I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.
1) Why do we have these two different project types?
2) Which do you prefer?
3) Why would I choose one over the other?
4) What's the deal with the *.aspx.designer.cs files?
They have different purposes.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.
1) The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).
2) It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.
3) See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.
4) The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."
MSDN Article describing the differences
Similar stackoverflow question
I won't duplicate the definition of the 2, since that just got answered.
So why use one over the other?
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
Pros
You can make tweaks to the site right on the web server
Deploying is as simple as copying the folder
Cons
If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page
Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.
Pros
Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.
Because you compile it on your machine, everything gets syntax checked at that point*
Cons
Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*
*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.
The simple answers are as follows:
New Web Site - creates code behind pages that are compiled at the server when page is requested.
New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.
Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
For more information:
Introduction to Web Application Projects
3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.
THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.
You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.
Nich
Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.
Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.
The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.
You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.
At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.
I -- and my workplace -- prefer the Web site project
We like that the files of the website are the files in the file system (no need to add them manually)
No idea
Here's two articles I found about both:
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
Note: A lot of the issues with Web sites have been resolved with the Web deployment project
Update: Fixed the point 1, Web application was there first
If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.
There is very little difference, and I would highly recommend using the Web Site model.
The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.
If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx