I have multiple web apps running on a server that all use a lot of the same css/image files. In order make everything more centralized i've taken all of the files out of the projects and wrote a small static file server in asp.net core with some gulp tasks to manage the css. The goal was to have it act like a cdn (with only one machine) and serve some other api functions, but to work locally without internet access.
I figured that if i included the visual studio project in the solutions for my other projects they would have access to the css/scss files for intellisense, which was not the case.
Is there some way that i can reference the files in visual studio so that i can get auto completion in the apps' view files?
I solved this problem by creating a symbolic link that included the assets in the desired project.
Related
I am creating a javascript webApp and i deploy it using GruntJS. this web app will be deployed in an ASP.NET MVC Web Service. I want to add the dist folder (and any files created by grunt inside the folder) programmatically inside the visual studio project, so when I build and deploy the web service I can navigate to this folder. Hope I was clear!
Yes you can. Grunt is completely independent of IDEs and texteditors and is a really helpful tool for all kinds of web development in any editor.
Grunt is described as “a node based javascript task runner with which you can automate tasks like minification, compilation, unit testing, linting and more”. You can use it for example when you do not like to be dependent on an asp.net web server doing minification and bundling for you, or you simply like to be able to use tools that are not (yet) supported by the asp.net/Visual Studio ecosystem.
Here is all you need: http://joeriks.com/2013/08/06/can-i-benefit-from-grunt-for-my-visual-studio-based-web-development/
Hope this helps!
Try to tweak WebDeploy settings in your MSBuild file (*.csproj?) so it would include files from the dist folder into your web application during publishing.
The following tutorial should be a good starting point how to do it:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/deploying-extra-files
Also check ASP.NET Solution Template on Visual Studio Gallery
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.
I have created my first website using asp.net 3.5 .
I have used App_Code for managing my source code files.
Now, after completion:
List item
What needs to be uploaded to the server ?
Do uploading all file including webforms files, source code files make any sense ?
Please provide your own suggestions apart from these.
You should look in to one of these several very good tutorials and articles about deploying ASP.NET applications.
How to Deploy ASP.NET
15 Seconds: Deploying ASP.NET
Deploying ASP.NET Applications on IIS 6
Deploying ASP.NET Applications
Now to your thoughts on what should be uploaded and what not. If you understand the asp.net cycle and how the files are processed by the webserver, it would be easy to know that all files need to be uploaded. But since this is your first application you probably don't have that knowledge.
So, to save you some reading time, Upload everything. In older versions such as 1.1 you had to compile all your source-code into binaries, which you don't have to anymore, but you can, it's up to you.
I However prefere to upload all the files without compiling it to binaries, makes it easier to manage once they are on the server.
The webserver will upon request ( first request ) compile these and then use the compiled files on other requests, this is the short answer anyway, this is why the load-time is longer the first time and the other times it's ( suppose to ) go faster.
Also, worht to know is that if you change the web.config, the application will re-compile.
So just drag n' drop em' to your webb-location and start playing!
If you are using the App_Code folder, it sounds like you are using a web site project type. In this case, the easiest thing to do is just xCopy all of the files up to the webserver. IIS will then do Just In Time compilation (JIT) the first time a page is hit, and will compile your code on the fly.
rgds,
Paul
All content files (i.e. aspx, ascx, asmx, asax, js, css, htm, jpg, gif, png) and DLLs need to be deployed to the server. I recommend using the Visual Studio "Publish..." option on the Build menu to do this for you. It can deploy to a folder (which you can then copy to somewhere else if you like), an FTP site or to an IIS virtual directory.
Uploading your .cs or .vb files is not necessary. It will still work if you do but it's probably safer not to. There's a remote possibility that IIS will have a vulnerability or a sysadmin will make a mistake and your source code will end up being served to the public.
In Visual Studio you could could do File -> New Web Setup Project and build an MSI to do it. This article and This article have more details on this option.
I'm using a Web Deployment Project in Visual Studio 2008 in order to prepare my ASP.NET application (ASP.NET web application, not ASP.NET web site) for being copied to several servers. I have to copy the files on local staging servers, on different servers via FTP and sometimes I have to fetch them from customers' servers.
So, it would be nice to have all files for deployment in a compact form without the necessity of doing a lot of comparing between source and destination. Web deployment projects have this nice feature: compile all your aspx and ascx files into a single (additional) assembly.
I somehow found out how to get rid of aspx placeholder files on the server, now I'd like to know if there is a (maybe self-made) way to get rid of these .compiled files.
From Rick Strahl's blog:
The .Compiled file is a marker file
for each page and control in the Web
site and identifies the class used
inside of the assembly. These files
are not optional as they map the ASPX
pages to the appropriate precompiled
classes in the precompiled assemblies.
If you remove the .Compiled file, the
page that it maps will not be able to
execute and you get a nasty execution
error.
Anybody out there with a creative idea, maybe using a module/handler which intercepts the check against the .compiled files in the bin folder?
The .compile file comes from pre-compiling on deployment. So you basically have 3 options:
Keep the .compiled file
Don't pre-compile and deploy source code
Turn this in to a Web Application instead of a Web Site and compile as an assembly
I have run in to the same problem myself. I actually choose #1 in most cases when dealing with deployment of Web Sites, but on the rare occasion when I know I am going to have to maintain the site for an extended period of time, I take the time to upgrade it to a Web Application.
I don't like the .compiled files either, but nobody gets hurt if they're there. So why bother?
You might want to take a look at Virtual Path Providers (KB how to here) in ASP.NET.
Credit for this suggestion must go to Cheeso and his self answered question here:
Can I get “WAR file” type deployment with ASP.NET?
I don't know about the .compiled files, but you could set up your servers to update their files with subversion instead of manually copying the files when you compile.
So you would compile the files using the Web deployment project (not into a single assembly), put them in a repository you created for this purpose, and on each server, just do an svn update to fetch and compare the files automatically.
I know it's not what you asked for directly, but it may be a path to explore.
Add "Exclude Filter" to your deployment project:
In the Deployment Project.
Right Click on Content Files.
Click on "Exclude Filter".
Add "*.Compiled"
click OK.
and thats it.
I remember at the days when I cant do Web Application with VWD Express, I use nant script to compile the project into a single dll and deploy, that would work (so I dont need the full VS to do dll deployment too), so if you really don't want to mess your project to Web Application, maybe this is a path to check too.
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
If you publish your code as updateable (in publish settings) these files are generated. Uncheck that value and republish. This is an old question I know, but no answers are clearly defined for this here.
I'm a total newbie to SVN and haven't been able to find an answer for the following situation.
I have an ASP .NET 2.0 web app that I am developing. I am using my local IIS as the development web server (i.e. not the Visual Studio web development server). My development environment is VS2005, Vista, IIS7, TortoiseSVN / AnkhSVN. VisualSVN is installed on the server.
My .sln files and class libraries, etc. are located in the **C:\Localsource\Projects\ProjectName** folder, and my .aspx files are in my **C:\inetpub\wwwroot\ProjectName** folder.
I can set up the repository for **C:\Localsource\Projects\ProjectName** fine, but can't think of a way to set it up for the IIS folder as well in the same repository.
What's the best way for dealing with this development environment in SVN?
Many thanks,
Ant
In a solution in Visual Studio you can have a class library project which is usually in a directory underneath the .sln file.
In this case he also has a web project within the solution but NOT underneath the .sln file in the file directory structure.
He will be attaching to this project via HTTP not via local file path.
IIS will manage this as http://localhost/webapp and by default will place it in c:\inetpub\wwwroot\webapp. The files in webapp folder will not be in the repo as they arent in the hierachy of the solution and the class library. This is his question how to sort it out.
My answer is to move http://localhost/webapp to point to a folder that is underneath the .sln file and adjacent to the class library directory then it can all go in the repo.
Seperating the class library and the the webapp is best practice to aide code re-use and decoupling the logic from the web site.
Can you not just point IIS to C:\Localsource\Projects\ProjectName and set the permissions?
Hmmm - Good point. It was set up like this when I got here, and Visual Studio always creates websites in the wwwroot folder, so I assumed wwwroot was just where they had to go.
Maybe I'll have to think about doing a little rearranging...
Thanks!
The IIS folder is not the output of the code base it is part of the application. It's not CGI output or anything but actually the scripts to run the app!
This is the .aspx pages that will have user controls and HTML to actually run the application. Its part of the applciation but split away from VS Studio solution.
The easiest way is to have a solution and then C:\Localsource\Projects\ProjectName\WEBSITE.
Point IIS at that folder as well.
OK, I may be being stupid here but.. Why do you need to add the IIS folder (i.e. the output of the code base) to your repository?
Update
I think I should clarify this a bit more.. What I mean to say is I am not sure why the ASPX is seperate from the project anyway? What is wrong with an Web Project and n Class Library Projects in a Solution, added to your repository.. You then publish on each new release..
If it is simply a case of "it might be easier to roll back the published output" then so be it, I was just curious as I have not seen many people actually work that way.
Deployment of solutions in this structure would be a lot easier as well..
I think you might want to separate this into two problems, following this recommendation from Dillorscroft.
First, with regard to the material on your development server that is published to the production site, I think you need version control for that. First so you can roll back any page, and you can also decide when you have a stable level of the development site that you want to extract to production. (I would get that from the source control system into a site image and then synchronize that image with the production site.)
So, for the first part, we are talking about versioning the web pages and all of the custom server-side material that supports the web site.
Secondly, With regard to the development of components that are used on the site, they need their own development projects, since it is the result that goes to the development site, not all of the source, libraries, etc. that the component is built with. So these will have their own project development tree (think of it as if you were building a library that is to be used by other development projects, although in this case the other projects are web pages). So the only thing that should show up in IIS is the "deployed" component to the development site.
There seem to be three critical questions for you:
How development of tests that need to go against the web site is handled and where that is version controlled (assuming they do not belong on the web site itself)
How easily you can arrange to make sure that all content on the development web site is kept under version control and checked-in and -out appropriately. (This has to do with the tools you use to edit web pages and other server-side gunk other than components developed off to the side.)
Easily taking developed components from the projects that produce them to the development site and have them be checked-in there.
My solution to (2) and to version control of the development web site is to use Visual Source Safe integration with IIS and FrontPage extensions that places the site under version control. Components produced from other development projects are mapped to the server project by VSS sharing.
For SVN, I speculate that (1) you want to see if there is an SVN adapter that IIS will recognize as an external source-control system and, either way, (2) have a discipline that takes delivery of components from their construction projects into the overall web site project.
Rob,
Why do you consider an .aspx file an output of the code base?
It is part of the code base. It's not an output after compilation for instance.
Just wondered?