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.
Related
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.
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.)
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'm working with Visual Studio. There I have a solution with several web-projects (.net MVC 4). All of these web-projects use the same javascript-libs. Currently I copied the library into each project, but this can't be the final solution. What is the best approach to share those library (assets in general) between all of the projects? Just link them? Or is it possible to create a project and reference it in all projects?
Update
"Link" the javascript files from another project is not a possible solution as I would have to link thousands of files (one of the libraries I am using is ExtJs) what makes it impossible to build a project without freezing visual studio...
Possible solution
Currently I have a (Web) MVC Project called "Web" and a (Class Library) Project called "ClientScript" which contains all the JavaScript files which are shared between several Web Projects. As linking all the needed JavaScript files is not a possible solution (because it's a matter of thousands of files what causes visual studio to freeze) I copy all the needed JavaScript files to the individual Projects using the Build Events in each Web Project (Project -> Properties -> Build Events -> Post-build).
My Post-build command line in the Web Project looks like this:
start xcopy "$(SolutionDir)ClientScript\Frontend\*" "$(SolutionDir)Web\Scripts" /r /s /i /y /D /E
Every time you build your Web Project all the changed Javascript files get copied from the ClientScript Project to your Web Project.
While developing the Javascripts I run a small "filewatcher" tool which automatically copies a file from the ClientScript Project to every Web Project when it changes. This way I don't have to build the Web Project every time when I make a change to one of the Javascripts.
Anyone that stumbles across this question here in the future should know that there are now Shared Projects in Visual Studio to solve this problem. Universal Windows projects use them by default and you can create your own by downloading and installing the VS extension here: https://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
Note: At this time they can be picky about what type of project you try to add the shared reference. I created a JavaScript shared project to share js files between a Windows store js app and an MVC web app and it would not let me do that saying they had to be of the same language. (It supports C#, C++, or JavaScript).
Place the JS files in a single folder, likely above all others, and add them to the project but use the "Link" option. It's part of the drop down on the "OK" button in the "Add existing item..." dialog.
When you run every new ASP.NET MVC 4 project it's take a new port then other app have take.
I simply suggest you a simple thing.
run a project which contain all the pacakages. open them webmatrix and run them as localhost:80.
You need to set the port in settings section of your site in webmatrix. Now it will rechable at localhost now you can reference all the libraries from this packages.
Slightly older thread, but I have another way of doing a similar thing using Web Essentials, that handles the issue of not publishing correctly.
I have a shared folder outside of the projects that require the shared file, normally a 'common' project with other things in as well, but can be just a simple folder as suggested by Michael Perrenoud.
However instead of 'Add as Link' I have been creating a new bundle in the project that requires the shared js/css file, with the same name as the shared file, and then referencing that file in the shared folder using a relative reference location rather than the root based one it starts with.
To add a file from a shared folder in the root of the solution to the scripts folder use the following code in a new bundle file (*.bundle), changing the folder/file names as required.
<?xml version="1.0" encoding="utf-8"?>
<bundle xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://vswebessentials.com/schemas/v1/bundle.xsd">
<settings>
<minify>false</minify>
<runOnBuild>true</runOnBuild>
</settings>
<files>
<file>../../MySharedFolder/my-js-file.js</file>
</files>
</bundle>
Then every time you build it recreates the bundle with the latest version, this version is then also published as expected :)
You can even create a minified version if desired by changing 'minify' to true. Or better yet you can add them loads as a bundle too if you want, you have that flexibilty.
This is an older thread but due to complex business requirements these days applications are divided in to different modules or sub projects.Thus, brings us the need to share common resources like JavaScript files, themes and CSS style sheet files.
I personally feel that common files should be put in separate Asp .Net MVC 5 project which has following structure :ASP.NET MVC5 folder structure
Now the best part is you can separately manage the dependencies using Bower,NPM or Nuget package manager.
After you have organised all the files in this project host this project to your own CDN or may be on cloud. You can use Using CDN in Bundle Approach to get script or link references.
That will help you sharing common resources across all the projects.There us a short coming though if you have many developers on the team and if someone added incompatible version lib can affect all the apps.
I have a Silverlight 4 app that I'm building with Visual Studio 2010. I'm using Mercurial/TortoiseHG to do version control. Which files do I need to check in? By default, it checks in all sorts of .dlls in /bin/debug and stuff. Do I really need those? Or can I just grab code and content files? Do I need to version something to keep track of project properties and references, or is that contained within the .csproj file itself?
You don't need to include stuff in /bin or /obj. This is true of all VS solutions in source control. These are recreated upon every rebuild. Also, for Silverlight specifically, you don't need to check in the XAP file that is generated in the ClientBin of your web app.
From MSDN (via this social.msdn thread):
You can add the following files to Visual Studio source control:
Solution files (*.sln).
Project files, for example, *.csproj, *.vbproj files.
Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.
Files that you cannot add to source control include the following:
Solution user option files (*.suo).
Project user option files, for example, *.csproj.user, *.vbproj.user files.
Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.
Build output files, for example, *.dll and *.exe files.
It doesn't say anything specific about Silverlight projects though.
Is Mercurial/TortoiseHG integrated into Visual Studio? i.e. can you check out/submit from within VS?
If so, if you right click on the project name and select "Add Solution to Source Control" it should add those parts of the project that it needs ignoring everything else.