What is different type of build action and how it affect our code
Why would .cs files default Build Action be "Content"? It seems like "Compile" would be more appropriate.
edit: I created a test .cs file (Class) in the App_Code folder for my test and I am using Visual Studio 2015 (fully updated). This is using the default Web Application template (MVC) in Visual Studio.
edit2: I just did another test and the same thing happened. Maybe the cause is the project type I am using (ASP.NET MVC Web Application). It seems like the App_Code folder is the recommended place to put cs files, however, since nothing from this folder can be served to the client. I haven't made any changes to VS2015's configuration or anything like that.
Related
I have a project solution in visual studio. Its created with MVC .net
I want to move some of my code files such as index.cshtml and others out of the Views>Home folder and into only Views folder. Will this break my project?
Also I want to rename index.cshtml to a new name, throughout all instances in my solution. When I tried this it only did the one file and it broke the project. I tried a CTRL F to find all index.cshtml, but it said there are no instances (though I know there are)
I need to rename the files correctly, so that I can deploy my project to match a current setup.
How do I rename all instances of index.cshtml in visual studio ?
And will moving the files outside of the home folder break the project?
I tried this it only did the one file and it broke the project. I tried a CTRL F to find all index.cshtml, but it said there are no instances (though I know there are)
If you just starting out I'd recommend not moving/renaming view files by hand. Eventually you'll have good understanding of how view discovery works and will be able to move files to places where they can be found at run-time (and even add more places yourself).
ASP.Net is convention-based approach to locate view files - short version is by default runtime looks for .cshtml files with this name format "/views/{controller name}/{action name}.cshtml", you can change view name by specifying different name when returning View("MyOtherView") from controller.
For detailed information on how view discovery works see Order in which Views are searched in MVC, how to change order of search viewLocation in asp.net mvc?, Microsoft - Views in ASP.NET Core MVC.
In my Visual Studio Solution, I have a Website project, as well as a Web project (the latter a Class Library containing things like web-specific logic, HTTP handlers, etc.)
I would like to include shared static assets in the Web project like JavaScript and HTML template files. These files will be referenced and used in the Website but may be used in one or more other projects in the future, so I would like to keep them in a common project. Ideally they'll end up somewhere like /js or /templates in the Website. I'd prefer them not going in the /bin directory if possible, but I could be convinced that it's fine.
That said, what would be the most appropriate way to keep them in the Web project, but have them deployed with the Website at build/run and deployment time, whether debugging from Visual Studio or building with Jenkins/MSBuild? The options I see are "Copy to Output Directory" or some sort of embedded build action (not ideal, as I would like to copy the files into the output directory in their native format.)
Any classes I create in the /App_Code or /App_Code/[subfolder] don't have local intellisense.
That is - I have intellisense for system dlls such as string.[member] etc. But cannot get it to recogize any classes local to App_Code (including itself), or dlls referenced in the /bin folder.
Although I do have intellisense of inside the scope of a member-function. (ie. local variables or function parameters)
NB
This is a Web Site project, not a Web Application project.
I have tried resetting all the Visual Studio settings and clearing the intellisense information found in AppData for VS.
Im working with Visual Studio 2012 ver. 11.0.61030.00 Update 4
The project is using .NET 4.0
If I move the classes outside of the App_code folder, they register in intellisense perfectly.
There is no option to set the Build setting of the files to Compile as this is a web site project rather than a web app.
IMO, you should move your code out of App_Code. In .net 4.5 (and 4.0) your behind code is compiled to a dll, so I don't see any benefits to putting your code in App_Code. If someone advises different, I am interesting in hearing.
With that said, create a folder or folders under your root project and put your code in there.
MyWebsite
- DataLayer
MyDataLayer.cs
Default.aspx
In this example, you will be able to access your classes DataLayer.MyDataLayer
Even better create a new library for code that is not needed in your aspx.cs code behind files.
New code files in App_Code will have the build action "Content", hence you got no intellisense.
So right click your code file and click "Properties", in the property window change the "Build Action" to "Compile".
Then reopen your code file.
In Brief:
In an ASP.net website with a code-behind, at what point are the *.cs files compiled?
Context:
A colleague who has since left, deployed a website with a .cs code-behind to a shared server. I have made a small change to a .cs file, which I should expect to reflect on one of the pages but it has not yet appeared. I have restarted the application pool, however I am loathe to reset IIS on the server as there are couple of other teams' apps which might be be in use on the same server.
This applies to Web Application projects as opposed to Web Site projects, which are CodeFile by default, and don't allow changing the build action...
In ASP.NET Web Applications you have two methods of deploying your pages; CodeFile and CodeBehind. By default pages will always use CodeBehind but you can change this.
CodeBehind
CodeBehind compiles your .cs file into the .dll file in your bin folder at compile/build time, and then you deploy that to your web server. There is no need to deploy the .cs file to your web server. If you do, it will just sit there being unused.
To configure a page with CodeBehind, ensure that:
The page directive in your .aspx file has CodeBehind="your.aspx.cs"
The properties of the .cs and .designer.cs files in solution explorer have a build-action of compile.
CodeFile
This causes ASP.NET to compile the .cs file on-the-fly on the server. This means that your .cs file needs to be deployed to the web server. It also means that your .cs file will not be compiled at compile/build time and therefore not built into your .dll in the bin folder.
Key advantage
With CodeFile, You can make changes to the .cs file and deploy just that file to see the changes on your production web server. No need to re-deploy. No need to recycle the app pool. This can be very useful in a lot of situations.
To configure a page with CodeFile, ensure that all of the following are met:
The page directive in your .aspx file has CodeFile="your.aspx.cs"
The properties of the .cs file in solution explorer have a build-action of content
The properties of the .designer.cs file in solution explorer have a build-action of none.
Notes
Intellisense doesn't like working when pages are set up with
CodeFile (you can change to CodeBehind whilst coding and then change back for deployment, though).
If you change from CodeBehind to CodeFile, then always do a
rebuild and re-deploy (and vice versa). This is because when the page was CodeBehind,
the .cs was compiled into the .dll in the bin folder, and will
remain there when you change to CodeFile. The CodeFile will be
compiled on-the-fly and you will get the same code/classes defined in
the .dll and in the on-the-fly compiled code, which will lead to
runtime errors.
For the setup I use, the .cs files are compiled when building the project. This means it is the .dlls in the bin that need to change, not the .cs files directly.
The .aspx files can change at any time, but I think you need to rebuild the project in order for the code behind to take effect.
I have replaced singular .dlls before without any problem (though it's not good practice).
Apparently what you have done should work.
Check if Cacheing has been implemented.
Otherwise publish the code and deploy the dll, instead of .cs file. I would recommend to test in staging server before you go live.
I have a C# application that uses several web services which were added to my project as web references. I want to know what files i should check into source control.
in my project there is a folder structure from my project directory that looks like this:
Project
Web References
WS
WS.wsdl
Reference.cs
Reference.map
...misc .datasource and .xsd files
Which of these files should i put in source control?
Thanks
Suggest keeping all those files under source control, but only for completeness for other developers using your project's source code, or having to perform a Checkout/Get Latest on any new machine (after your dev machine's hard drive dies, etc.).
Once Visual Studio builds the web reference, all those files are built and remain unchanged until you 'Refresh Web Reference'. If you modify them yourself, i.e. change a datatype, or remove an XML attribute (I've had to do that for some obscure runtime SOAP problem), then check those changes in as well.
If your nant script or visual studio solution or what have you rebuilds any particular files on each build, then don't check those in, as it'll just lead to confusion. Otherwise check it all in.