How to start asp.net application without .sln file - asp.net

I have a working codebase of a web application written as ASP.net webform application, Visual Studio community edition. How do I start the application. Meaning how do I start the application / debug,
Community edition IDE expects something like a .sln file which I don't have, or its not present in the codebase.
I have been writing code for more than a decade, but I am new to ASP.net, require some help.

Normally (as you note), you find(have) a .sln file.
However, if you don't, then usually you have (will find) a .vbproj file for vb,
or a csproj file for c#.
When you open these "project files", then VS will create .sln file for you.
However, the 3rd possibility is this is not a asp web site application, but a asp.net web site (note HOW VERY close the term is I used:
Asp Web site = (no sln, and no project file)
Asp Web Site Application = (should have a .sln, but you have one if you open proj file).
So, if no .sln file, and no .vbproj/csproj file is found?
Then you have what is called a asp.net web site.
They are VERY close in terms of editing, writing code etc. However, a web site is NOT opened as a project (.sln/.proj) file, but you simple use this option:
In this case, then when you select above option, then you JUST browse to a folder, and you don't have a .sln/.proj file at all. You are in effect just opening a folder that has the web site inside.
I don't have a great/nice link that explains the difference between a asp.net web site vs a asp.net web application.
However, the major difference is:
The Asp.net web application
near ALWAYS expects that you have a dedicated server to publish to (so lower cost hosting will not work).
You have both control over the whole web site features - can write custom page handlers. You have more options for authentication. In effect, you can code and change "base" features of internet services. So, you have direct use of the web server features - and can over-ride behaviors.
Asp.net web site
This really is just a sub folder. So, for example, this option can be used to up-load your web site folder to a existing server. And you can modify one page (and code behind), and you really don't have to re-publish. This option of course OFTEN has to be used if you using some low cost web hosting. You can't publish a web app, since it would quite much over write the server features - including the base starting page.
With a web site app? The whole site is re-compiled, and the whole application is compiled down to ONE .dll. (much like a desktop application, of course additional .dll's and libraries can appear as separate .dll's). but, they are usually all merged into one .dll.
So, the existing of .sln, or .csproj/vbprjo files will quite much tell you which type of web site you have.
While a web site app requires a full re-publish of the whole site - even for one small code change - I still prefer that setup WHEN that option is avaible. This is due to having additional options, and control over session() events, and more.
However, as noted, in a lot of hosting environments, you only get a folder and some place to shove up your folders and web pages - and thus full web app publishing will not be a option for you.

#albert-d Fantastic answer!! it led to a lot of development,some how i figured out something.
cd theapp
dotnet new web # Create basic web soln/app
dotnet run
This sort of created default web app on the folder
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: /Users/raj/theapp/
On the browser it give nice output
But when I try to execute my old files present, like
http://localhost:5000/Default.aspx
Its not working.
Giving following error
Looks like I am losing a battle for want of nail. Could you pls clarify.

Related

How do I properly deploy a website from Visual Studio and make this ASP based site function properly?

I'm sure there's something simple I'm missing.
I'm attempting to help a buddy move his ASP site from one host to another to avoid some questionable billing practices. I usually work with PHP-based sites (Wordpress etc.) and, unfortunately, have no experience with VS or ASP.
He's temporarily moving to Godaddy on their Plesk offering temporarily until he can work out something else. He provided me with all of the files contained within his ftp (containing his site's default.asp file, header, footer etc.) as well as an archive.xml, parameters.xml, and a systemsinfo.xml file. No .snl file or anything like that.
The files did not come with a web.config file. The error I keep getting, after uploading the FTP files is "HTTP Error 502.5 - Process Failure". From my understanding, it's often related to the web.config file. And from what I understand, you can have one generated by deploying the site through VS. Problem is, I'm at a loss as to what the proper actions to deploy this project.
Plesk provides a .publish settings file, I'm just at a loss as to how to properly open this file in VS to then have it create a "web.config" file and proceed to have it publish to the hosting. Part of this is I'm unsure how to properly open a project like this in Visual Composer to then proceed with the process of setting a web.config file and going forward with the deploying.
Not knowing exactly how to open this project without an .snl file or anything, I tried creating a new project and dropping in the other files to try and set up the process that way with no luck. Considering that Plesk provides a deploy file with that information, I'm assuming if I can properly open the project, working locally, I can then go through the deploy process. I'm just at a loss as to how I can properly setup a new project with someone else project files without an .snl file or otherwise.
Any guidance that you provide would be awesome.
Thank you.
Well, if you missing basic files required to operate the site such as web.config, then you don't have the site or files required, right?
Either FTP down the existing site, or you go to the source code and VS project, and re-compile the code, and re-publish. In fact, I suggest publishing to a local simple file folder.
Even publishing to a local file folder is a good start. Now, just copy that local folder that you published from the source code project, and that published folder should work on the new site. But, really, missing files like web.config? Rather fundamental that you have ALL files of that existing published site, or you have to go back to source code project in VS and re-publish.
since that site has vb.net or c# code? Then it also not clear if the original site was a
asp.net web site
or
asp.net web site application.
Rather critical you determine the above. The reason is that for a asp.net web site application, then at publish time, all code is complied at publish time, source code is stripped out, and then you have a working site.
If this is a web site (not web site application), then all source code is in fact published to the web site, and IIS is now responsible for compiling the .net code.
but, gooly, without a web config file, you simple don't have the files for that site to work - NOT even close!!!
but, as noted, if you have the original source code and VS project, then I would of course use the source code project for the publish. As noted, you can publish via FTP, and several other ways - but I in most cases use folder/file publish to a local folder, and then that is FTP up to the site.
You also don't mention if a database is involved. But, the connection strings to the database will FOR SURE change on the new site - and that boatload of required information will of course be in the web config file.
So, what road will much depend on if you going to download the exiting site, or your going back to the original source code and Visual Studio project.
So, first step - which will take about 10 seconds of your time is to determine if this is a asp.net web site, or a asp.net web site application.
If the existing published site has the c# (or vb.net) source code, then this was/is a web site.
If the existing published site does NOT have the source code, then of course this was a asp.net web site application - and Visual Studio is responsible for compiling the code BEFORE publish.
I guess this really comes down to if you have the source code and the original project used to build the site in VS or not?
I mean, if you have the source code (not compiled) of that site and have the full project in VS, then that's your best starting point. And if that site was published asp.net web site (application), then FTP and downloading the site WILL NOT get you a working asp.net project in VS.
This is much like saying you have a some .exe program, but don't have the source code and project used to build that .exe.
Same goes for asp.net. but, as I stated, often the web site as opposed to web site application model is used, and in that case, then you would get and have the source code files by a simple FTP download. But, you don't even have the web.config file - and that makes no sense at all, since that going to exist in the current site if you download, and it would exist in the original VS project used to create that site in the first place. During a publish, we often have an additional config file that has the local database connections, and during publish, they are transformed into the correct database connections for the published site. But then again, you not even noted or mentioned if a database is involved here.
I mean, if I was handed a LAMP project (Linux, Apache, MySQL, PHP), and had to publish that site? gooly, I not worked with LAMP, but I'm sure it would be a week, or more for me to figure that out, since I'm not familiar with LAMP, and how such sites are laid out, let alone how the configuration of such a site works. Big job if the whole system, programming language and framework is something you never used before.
I know that Godaddy use Plesk control panel too. But you need to make sure that Godaddy has support .NET Core. You may refer to this post https://dotnetblog.asphostportal.com/how-to-fix-error-502-5-process-failure-asp-net-core/. I believe it will solve your issue.

Deploying a Visual Studio website vs web application

So I'm using visual studio 2010 to build a website that was formerly running on PHP, so I'm pretty new to the environment.
In starting the project I built a website project, not a web application project. I know that will probably generate a lot of "never use a website project, use a web application project instead" comments, but bear with me.
I'm attempting to provide our server team with the necessary files to compile on our server for the first time. However they're used to working with web application files, not website files.
Normally they are given the source code and a batch file that compiles the code into deployment directories and then they just move the files to the server from there. I'm pretty sure that the other teams use deployment packages to do this, which obviously isn't an option for a website.
My question is, what would be the equivalent steps for getting the source for a website ready to deploy vs a web application? I have published the website to a separate folder and this has rendered what I think is the equivalent in many ways, but I wanted to make sure.
Also, is it possible to publish certain parts of a website without others?
Please with-hold all the comments about how I should be using a web application instead, google seems to assume that's all that's used out there too.
Thanks!
There isn't much to deploying a web site other than copying the source files to a directory in IIS. It will compile the site automatically on the first page request.
I agree with Britton. I personally prefer web application but with the web site project you have 2 options.
Either a) Upload all the files (including the .vb or .cs files) and the web server will compile on the fly. OR, you can publish to a separate folder locally on your machine, and then upload that folder. I would do the publish if you don't want anyone seeing your source code.

Turning a precompiled web app to a 'normal' web app

I've got a quick question about precompiled web apps:
I've recently took over a project done by someone else, which is a precompiled web app. This means that it has no App_Code folder, of course. Due to the nature of this project I would like to put my code on the server anyhow.
I can't just add the code, because I'll get an Exception stating that the App_Code folder isn't allowed because it's a precompiled web app. If I remove the file 'PrecompiledApp.config", then my application crashes.
So what are the correct steps in turning a precompiled web app to a compile-on-demand webapp?
Thanks for the help.
I can get this working in VS2010.
Go to your web app settings and select the Package / Publish Web tab. There's a drop down that's probably defaulted to 'Only files needed to run this application'. If I use this it just publishes the compiled DLLs to the server and the web files, but none of the code.
If I change this to 'All files in the project folder' then I get everything - all the C# code for my controllers, for example.
Of course whether you would want your production code on a server is a different question, and you also get all the VS solution files and stuff like that too so it looks quite messy.

How can I use the "Publish" function in Visual Studio 2008 without erasing the contents of the target folder?

When I use Build->Publish Web Site in Visual Studio 2008, most of the time it compiles the site, and then simply asks me "All files in the target folder will be deleted. Continue?" (or something to that effect). On occasion, however, when publishing a project in Visual Studio, I would get a dialog box that would give me the choice of replacing the folder's contents completely, or simply replacing changed files with newer version.
I much prefer to publish without completely obliterating the folder, because the deployed application creates user files and cache files as it's been used that I don't want to take extra steps to preserve. However, I'm not sure why Visual Studio doesn't always give me this option. Is this a setting somewhere I can change? Is it tied to the version of .NET I'm using?
Any insight is appreciated!
Edit - Followup on 2009-01-20
I still haven't figured this out, but here's some more information.
Here's what the publish function looks like for one ASP.NET project on my Win XP desktop:
And here's what it looks like for a different project on my Vista laptop:
Notice the radio buttons in the second screenshot that allow me to choose to either delete the contents of the folder prior to publishing, or merely to overwrite matching files. I'd like to have these options for every project.
Both computers are running Visual Studio 2008 Professional (version 9.0.30729.1 SP, according to Help->About). The exact same version. And I doubt the OS difference is causing this functionality change. It's got to be a setting somewhere, right? Does anyone know?
John is right, the only difference is one of your projects is a Web Site Project and the other is a Web Application project. You will not see the "convert to web application" option unless you are in a Web Application project. I know... it is very misleading. The reason behind this stems from the the way you convert to a web application project. If you plan on converting it(which can be a real pain in arse, depending on how it is set up) then you need to be aware of a few differences:
In a Web Application project everything is pre-compiled all the codebehind pages will be compiled into a .dll ---- In a Web Site Project nothing in the project is pre-compiled, the compiler will compile everything to ensure it is valid but none of the compiled pages are uploaded. When a user first attempts to access the site each page is compiled into its own dll. This means in a Web Site Project you are able to upload a single codebehind file.
Namespaces - In a Web Application project namespaces are created by default in a Web Site Project they are not. So you may have to spend some time adding them if you plan on converting them.
Project files - you will notice that A Website Project does not have a "cproj" file a Web Application project does.
I have converted a few of these project I find they go fairly smooth as long as there is not a lot of code in the "app_code" folder. You can give it a try and see how easy it is, if it looks like it is going to be a pain, I would suggest FileZilla just FTP it and save yourself some headache.
Good Luck
That dialog is different for Web site projects and Web application projects. In my MVC projects (Web application projects), I see the additional options. In my regular ol' web site projects, I see the first dialog posted.
Not sure if this option will be suitable for you but you could use the copy website function from the solution explorer. Click on the "Copy Website" icon at the top of the solution explorer.
I think the real answer to your question is that you should put your user files and cache files somewhere else.
When publishing a web site Visual Studio is designed to make sure that the target folder contains your web site files, and absolutely nothing else.
Apparently this feature is coming in VS2010 - that's what Vishal Joshi announced at TechEd EMEA in session "PDC307: Microsoft Visual Studio 10: Web Development Futures"
The site has been updated from the site in the updated layer.

How to make the process of debugging ASP.NET Sharepoint applications less time consuming?

I'm comparing it Java where you can start your application server in debug mode, then attach your IDE to the server. And you can change your code "on the fly" without restarting the server. As long as your changes don't affect any method signatures or fields you can just hit recompile for a class and the application server (servlet container) will reload the class.
I suppose this is impossible in ASP.NET since all classes are packed into assemblies and you cannot unload/reload assemblies, can you ?
So when you have an .aspx page and an assembly deployed to GAC and your codebehind changes you have to redeploy the assembly and reset IIS. I'm talking about Sharepoint applications in particular and I'm not sure whether you have to do iisreset for private assemblies but I guess you have too.
So the best way to debug aspx pages with code behind I guess would be to get rid of the codebehind for the time of active debugging and move into the page, then when it is more or less working move it back to codebehind. (This would be applicable only for application pages in Sharepoint, site pages don't allow inline code )
How do you approach debugging of your ASP.NET applications to make it less time consuming?
From Matt Smiths blog on how to get F5 debugging with sharepoint. A very cool trick.
Create a web application project in Visual Studio (File -> New -> Project -> ASP.Net Web Application, not File -> New -> Web Site).
Move the .csproj and .csproj.user files, along with the Properties folder, into C:\inetpub\wwwroot\wss\virtualdirectories\, where is the name or number of the web application corresponding to the SharePoint site you'd like to debug on.
Attach the project to an existing solution (e.g. STSDEV project).
Set as startup project (right-click project name, "Set as Startup Project").
Access project properties (right-click project name, "Properties") and click
Under the "Servers" setting, click "Use IIS web server", then enter the URL to the SharePoint web application you want to debug on, e.g. http://mymachine:99.
Yes private assemblies DO NOT require reset of the IIS. So you should just to xcopy new version to the application's Bin directory and refresh the page (e.g. by VS post build event as I did).
But there are some trade offs. You should decrease trust level in application web.config file:
<system.web>
...
<trust level="WSS_Medium" originUrl="" />
...
</system.web>
By the way. I do not suggest to deploy like this. It's just workaround for comfort write-test-debug cycle length.
If you are using the GAC, you can at least do iisapp.vbs /a "App Pool Name" /r instead of iisreset (it's quicker to recycle a single app pool than to restart IIS).
First, develop on a computer running SharePoint. Preferably, this means running Windows Server 2003 on Virtual PC or VMWare. This will let you deploy and debug SharePoint code directly, rather than having to copy files between servers and use the remote debugger.
Use a VS add-in to simplify the process of deployment and debugging. I've been using WSPBuilder but I think there are others out there. WSPBuilder has commands to deploy solutions, package them as WSPs, and attach your debugger to the local IIS process. It won't allow you to add/remove assemblies on the fly, but you can set breakpoints and run code through the Immediate window in VS.
Depending on how your production server is configured, it's usually a good idea to develop on a server with full/trust security settings, including disallowing code blocks in ASPX files. This makes debugging a little more difficult, but it reduces the number of nasty surprises you'll have when your code is finally deployed to production.
And you can change your code "on the fly" without restarting the server
You can accomplish this with ASP.net if you make a Web Site project (as opposed to a Web Application Project). Using a Web Site project, you can post changes to code-behinds without having to refresh anything on the server, and the server does the compile work for you on all code changes. See here for more info on this.
This should also solve your difficulties with deploying the assembly to the GAC. As the server handles all compilations for Web Site projects, you wont have to redeploy any assemblies when changing files.
Use an automated testing framework (NUnit) to write integration tests. This won't work for everything, but of course, it depends on what you're testing.
If you also have TestDriven.NET installed, you can run individual tests with the debugger. This has been helpful.
WSPBuilder Extensions has a "deploy to GAC" shortcut, unfortunately it never works for me. But it's a really quick way to code->compile->test.
If you're not using WSPBuilder Extensions, you can instead open a command prompt and run
gacutil /u yourassemblynamegoeshere
gacutil /i yourdllgoeshere.dll
If you do this often, you can put it in a post-build event or in a batch file. Also, I'm unclear whether the gacutil /u (to remove the DLL first) is necessary.
What it seems like you're trying to do is tell Sharepoint "When I start debugging in Visual Studio, use the version of the DLL that was compiled in the project's /bin/debug directory instead of the version of the DLL that is registered in the GAC." I haven't solved that problem, but here is how I debug Sharepoint.
A developer machine is Win2008, IIS 7, MOSS 2007, VisStudio 2008, and WSP Builder installed. Inside VS2008, a button is added to attach to w3p.exe process, Andrew's HOWTO attach to w3p
The solution file has two projects:
* First project is the .WSP that deploys all the app pages, including the DLL. Use WSPBuilder menu items for handling the .WSP creation and deployment.
* Second project is for the DLL behind the pages.
If you want the DLL to be copied to the GAC regularly, add a post-build event to the DLL's project that copies from /bin/Debug to the GAC. But, these days, I find I have just been recompiling the solution and then deploying the .WSP using the menu items, and then starting up the debugger using the button. It takes me an F-key and 3 clicks and about a minute for most of my projects, but I suppose it could be quicker.

Resources