So, I recently started with ASP MVC4 and on my journey I discovered several new technologies and frameworks, such as LESS, Bootrap etc. (because I haven't done any web application in years!) whose capabilities completely blew my mind. I worked my way through various tutorials and the only thing I learnt is: How bad they work together. I just can't get anything working and its extremely frustrating.
What I want to achieve:
Having bootraps less source along with other site specific less files in one directory, such as Content\style\less\*.less (also for JS files: Scripts\*.js)
Compile LESS files at build (pre-build)
Copy all files to custom build directory, e.g. bin\style\*.css
Minimize and optimize css and js files in output directory.
Bundle all together at runtime
What I fail at:
Copy ALL files to custom build directory. Visual Studio just compiles the code and copies it to bin\
Compile less files properly. I created a pre-build instruction with the dotless.compiler.exe, but it fails at simple tasks, such as copying to new directory or reverse directory compiling (when I say compile \Content\style\less\*.less it just compiles every file in this directory, not in directories below.
Optimization and minify: It seems that the Web.Optimization bundling instruction only work at runtime, not at build time!
I hope anyone can help me.
Technologies and frameworks I used: ASPX, MVC4, Razor, dotless, Bootstrap, Web.Optimization
Edit: Regards the output task: Am I expecting too much? Compiling an application and copy every necessary resource to a seperate \bin (build) directory is a common element in .NET application production lifecycle for ever. Why not for ASP sites, since they are called applications aswell.
After installing Web Essentials, Shift+Alt+Y is the default keybinding for triggering a recompile of all .less-files.
Related
I have students in high school who have created some programs using Visual Studio C#. They created some games and would like to now upload them to the web. I am pretty new to Visual Studio C#. I thought after a program was "built" that you could go into the bin/debug folder and get the exe file for the program and be able to play the game without having to have Visual Studio on the actual computer you are playing it on. It works with some of their games but some of them, there are graphical files that are missing in the exe file if all the other files aren't stored in the same place. How can I get a clean exe of their game? Can that exe be loaded up onto a web server so they can play it from there or at least download it from there?
Microsoft wrote a guide on how to do exactly this. It's on their MSDN website, which is sort of like the developer back-bone for a lot of Microsoft software and documentation.
Old guide: Adding and Editing Resources (Visual C#)
Newer guide: How to: Add or Remove Resources
The gist is that the program needs to know where the files are, relative to the location of the compiled binary (in this case, an .EXE); There's several different ways to do this, depending on your level of expertise. I would suggest that you take a look at the guides above to start that journey.
there's a few ways of doing this. (Also, make sure you're creating a 'release' build when you compile).
You can include resources in your game by creating a resources file. This is something I usually do only on winforms applications etc.
If you have on-disk files you need to distribute those on-disk files along side your game. You could do this by zipping up your game.exe and the /files/images.img folder (or what ever your resources content folder is named).
If you're feeling adventurous you could create a 'deployment project' which is a project that allows you to create an installer file. This is a bit more work however you will have fine grained control over what files go where etc.
Good luck!
EXE files generally aren't self contained for video games with many resources, just add resources in an external folder and make sure the paths to the resources in their games are not absolute but relative in the local directory.
So for example:
get rid of paths like C:/Users/Bob/Desktop/Game/Images/player.png and replace with /Images/Player.png.
Also, an EXE generally doesn't run client side on webpages, it is possible but difficult. Things such as Flash are made for this sort of issue. I'd say make the webpage a place where they can download their games. Github has a nice way to do free websites called gh-pages. OFC, you could host one yourself but that would require a lot of setup work.
Like Monza said, you can zip up the files for download. Or, you could create an installer if you wanted to be really ambitious.
I thought after a program was "built" that you could go into the bin/debug folder and get the exe file for the program and be able to play the game without having to have Visual Studio on the actual computer you are playing it on.
That is correct, given that the other machine has the necessary .NET framework version installed AND any other resources like .dll files and config files are also present. When the application is ready for release, you can set the Build options in the project properties to Release, and then when you build all the files needed for distribution will be in the bin\Release folder.
It works with some of their games but some of them, there are graphical files that are missing in the exe file if all the other files aren't stored in the same place.
This may depend on how the application was written. If resources like pictures are embedded in the assembly then those files will not be needed to run on another machine. If the application is using hard coded paths for the image resources in the source code, then the application will likely break if the necessary files aren't present when the .exe is executed.
Can that exe be loaded up onto a web server so they can play it from there or at least download it from there?
Yes - you could upload the .exe to a file server to make available for a download, but you would not be able to run it within a browser over the web. I would recommend zipping up the .exe and other files needed and hosting the .zip file on the web server for download; browsers may give a warning or block downloading an .exe .
Hope this explains it a little bit for you.
I'm new to ASP.NET, and making a small update to a site that already exists. I am confused about the differences I see on the production server vs. the source code I've been given, and would appreciate any explanation or advice. Normally I would just continue reading and researching until I understood fully, but in this case I've been asked to make a small update to something ahead of my understanding. All I need to do is change one element in a form.
On the production site, there are files like \contact\survey.aspx; no .cs files exist in the directory alongside them, and there's no CodeFile directive. Instead, there are a multitude of DLL files corresponding to these pages, like bin\App_Web_survey.aspx.fdf9difs9.dll.
When I was given the source code of the site to edit, I see something different. The bin folder is entirely lacking in these DLL files corresponding to pages; instead, each aspx file has an aspx.cs file sitting next to it in its folder, a code-behind. Fair enough, I think; the site can run in its interpreted mode, like this, or compiled to DLLs.
Problem is, for the life of me I cannot work out how to do that; I've read dozens of pages on the MSDN library and gotten nowhere.
I am using Visual Studio Express 2013 for Web, and I've opened the source code folder as a website. When I run 'build', it succeeds, but no DLLs are made, not even in the Debug folder. This MSDN page has instructions for compiling web application projects, but the options don't correspond to the available options for me, so I'm guessing that either web application and web site are distinguished or that Visual Studio 2013 (which I also tried using and had no luck with) is distinguished from VS for Web. I'm at a loss.
tldr: Can anyone quickly sum up for me the process of compiling an ASP.NET website in a way that results in multiple DLL files in its bin directory?
You might need to use aspnet_compiler:
aspnet_compiler -p sourceCodeRoot -v / targetRoot
See How to: Precompile ASP.NET Web Sites for Deployment (MSDN).
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 an issue where a dll shown twice in the Modules debug window for my WCF service (hosted by an IIS Project).
They are both loaded from my "Temporary ASP.NET Files" folders.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\d9bf3211\b2544e2b\assembly\dl3\4cfa5823\28f464b9_9a03cd01\InversionOfControl.DLL
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\d9bf3211\b2544e2b\assembly\dl3\4cfa5823\2457a584_9803cd01\InversionOfControl.dll
The paths are almost exactly the same, but the folder name that holds the dll is different.
So here are my questions:
What is "Temporary ASP.NET Files" for?
Why not just reference the dll that is in my build folder.
How could I have gotten two?
How can I prevent it from happening again?
If I just delete them will this problem be "fixed"?
The ones in bold are the answers I am most interested in.
You can feel free to delete anything below Temporary ASP.NET Files. All of the contents will be generated again (albeit with an initial performance penalty).
Also note that it is easier to use explorer to do this if you kill IIS temporarily. (iisreset /stop, delete the files, iisreset /start).
All you need to know different approaches for compiling your code by asp.net.
Do pre compile your code in order to avoid compiling and storing compiled files in temporary folders.
Hope this article will give you better answer for your questions. http://www.asp.net/web-forms/tutorials/deployment/precompiling-your-website-vb
Deleting them has no negative impact to your system.
.Net will just keep creating them slowly but surely filling up the drive. On dev machines, there are a lot of them. On servers... well, you shouldn't be deploying code to the server that requires compilation anyway.
Regarding whether it will fix your problem... maybe. Go for it.
why x86 folder exist in obj folder in c Sharp project file?
My project file structure is
ProjectOne
----------Bin
--------------Debug
--------------Release
----------Obj
--------------x86 //Why this?
-------------------Debug
-------------------Release
----- My source files.
Why my file current Directory is bin\debug, not projectOne (where my source file exists)?
When executing, the current directory will default to wherever the executable is - which will be in your bin/debug directory.
You can set where you want it to run from when you start it in Visual Studio though (in the project properties - if you need more details, please say exactly which version/edition of VS you're using).
As for the contents of the obj directory - you can pretty much ignore the whole directory. It's full of intermediate files that Visual Studio builds and then consumes - but you almost never need to use any files from there directly.
The x86 folder refers to the target platform for your build in your build configuration manager. It allows you to build 32 bit applications on a 64 bit OS. As Cody and Jon say you can ignore the obj directory.
The bin folder contains your application's binary files (that is, your executables). It is subdivided into two (or more) folders—typically Debug and Release. These correspond to your build configurations. When your project is compiled, the executable files are placed into one of these folders, depending on which type of build you conducted. If you want to run your executable outside of the development environment, you can click on the ".exe" file you find in one of these folders.
If you wish, you can change where Visual Studio outputs your executable files during a compile using your project's Properties window.
The obj directory contains intermediate (or object) files that Visual Studio builds when compiling your application. It's not really something you ever need to worry about or use the files from.
Finally, your source files are kept in the root directory, as displayed in your Solution Explorer window. You manage the locations of these files yourself; they are not managed by Visual Studio.
Object files (the files stored in Obj) are compiled binary files that haven't been linked. Think of it as fragments of the final executable that will later be combined to make your executable.
When compiling your source code each source file will loosely be compiled to one object file. Why? No reason*, just how your particular compiler was written. There are other compilers in other languages that does not do this but instead compile everything into a single large binary in one step. But the people who wrote your compiler decided to first compile to separate object files.
Now, you can imagine that if each source file generate one object file then every time you compile code your source directory will end up being messy and be filled with lots of .obj files (and indeed a lot of C compilers traditionally did this). Over time, developers working on large projects started to write compile script or configure their projects to collect all .obj files in a single directory to make the source directory less messy.
The people who wrote your compiler obviously liked the idea of a separate Obj directory so they made it the default configuration of projects. As for why there is an x86 subdirectory that's because your compiler also supports other CPUs like ARM (for Android, Win Phone 7 and iPhone) and also to differentiate between 32bit and 64bit.
* note: There are actually some very good reasons to do this including making the compiler code more modular and to support incremental compilation but the fact that some people can do all that without generating separate obj files mean that it is mostly a design decision by the developers of the compiler more than it being a necessity.