ASP.NET User Control - Build on Every Change - asp.net

I am working on building a User Control Asp.net - VB.Net.
When we do any change to User Control Code we have to build the project to see the code change.
Since the project is huge take a long time to build - can you suggest any shorter or better way or tips that can reduce the project build on user control code change
Right now when I change any VB code , I need to build project and then go to page to see the code change.

I was able to reduce the build time by doing a command line build. using msbuild - it was faster.
Additionally, I tweaked command to just build the web project only
msbuild EBR.Web.vbproj
Hope it helps someone else as well.

Related

Code to Test In Blazor WASM (make it NOT slow)

How can I faster test changes in Layout using Blazor?
I used to code websites in good old Apache+PHP+MySQL. and now I am starting with some development in Blazor.
But I find it difficult to work on the user interface. When I need to test a small change, for instance moving a entry in a web form from one row to another...
Blazor WASM development process:
Edit the code
Shutdown the browser
Recompile (Pray that it compiles...)
Wait for the webapp+API-App+Identity App to startup
Navigate to the page I am making layout on.
PHP+X Process
Edit the code
Press F5
I wish for a similar experience.
How can I decrease the development code/test UI time when using Blazor?
The simplest way to do interactive development is using dotnet watch run from a command prompt (I add a .cmd script to my projects to run this for the project). This will run the project and watch for changes to files, then re-compile the project.
On .NET 3.x Blazor you'll have to refresh the browser (F5). On .NET 5 projects it does this automatically.
You may also want to read RĂ©mi Bourgarel's Blog article on this, although I am not sure all his points are still valid if you're using .NET 5.

VS2010 Automatically rebuild minified .js/.css files

Problem:
I have been trying to integrate minification of javascript and css files in our VS2010 (.net 4.) projects. From what I hear, .net 4.5 and VS2012 will have minification build into the editor, so it will be as easy as setting a flag it will work. Unfortunately we are sill on VS2010 (.net 4.0).
Let me explain what I want to do and what I dont want to do.
I dont want to do big setups with classes/config file(s)/etc just to minify because all that stuff will have to be loaded on our build machine and even the build xml files might have to be modifies to make it work. Also, once we go to vs2012 and .net 4.5 all these configs/classes/etc will have to be discarded because vs2012 will have the build in functionality.
Here is what I think might be the best option. Since I am using the ScriptManager and it can already pull either a .debug.js (non-minified) or a .js (minified) script based on the build type, it seems all i need to do is to have some sort of (pre?) build event that will re-build a non-minified .js file into a minified one. Obviously the build event will have to call a minication module which would have to be installed on local computer (the YUI Compressor seems very nice). The module would update the minified .js file.
I have been reading about this, but I am getting a little bit lost. There are a lot of third party tools with bunch of setup and classes which I do not want to add.
Did anyone do something similar as I explained about?
If not what is the next best simple solution?
(By the way, if you are going to say move to VS2012/4.5, thats not a solution for us at this point)
Solution:
Thank you Parv Sharma for your answer.
I would just like to explain what I did so that it may help someone in the future.
I installed the Microsoft Ajax Minifier
Created a batch file to add minifer to ENVIRONMENT PATH variables: setx path /m "%PATH%;C:\Program Files\Microsoft\Microsoft Ajax Minifier"
Added the following pre-build events into my project:
ajaxmin $(ProjectDir)Script.js -out $(ProjectDir)Script.min.js -clobber
If Script.min.js does not exist, it will be created by the build event, but it will not be added to the project (not sure how to do that through the events).
When you add a new script file, mynewscript.js, just create a second blank file called mynewscript.min.js and add an pre-build event for it.
Using this approach the only thing you have to do to the build machine is run the Microsoft Ajax Minifier setup package and the batch file. Thats it everything else will be part of your pre-build events.
what you are looking for is probably this
http://ajaxmin.codeplex.com/documentation
by using this you would be able to use this third party tool as the minifier
after downloading the tool you have 2 options
1. edit the MSBUILD file to include building the js as per build event
OR 2. to attach this tool to VS and assign a key compbination to it.. this way you would be able to minify whenever you want just like we do F5 OR Cntrl-Shift-B
Attaching to VS is easy just to to external tools and in the Tools menu and add this tool with the required params

After MVC3 publish, just update the views

.NET/MVC3 newbie, so please bear with me!
I've searched for this answer all over but cant find exactly what im looking for, so here it comes...
Lets say that i'm developing an MVC3 app with Visual Web Developer Express and i go about deploying the site using the built in publishing tool.
But now that my site is up and running i find that i need to make a minor adjustment in one of the views. I update the view and save the file, and use my FTP program to upload the new file.
The problem is that MVC3/.NET doesn't seem to refresh/change the view, because it's still using the old version.
Of course I have tried refreshing (in many different browsers even), but it still won't load the new view.
Is this normal behaviour, meaning that i have to publish every time i make some minor adjustments (kinda time consuming)? I really can't imagine that this is the case, so i'm wondering if you could shed some light over this?
Appreciate any replies!
/Mikael
If you upload the view (.cshtml) file and that is the ONLY part of the application that has changed, a refresh will reflect the change - you may have to ctrl+f5 to clear the temp cache. However! If you change ANY of the controller code or action code, or any c# (or vb if thats what you use), then you MUST re-upload the compiled .dll associated with the entire application in order for the changes to be reflected.

How do I get the build to break when someone uses AutoEventWireup="true"?

Our application registers events OnInit. When developers create a new aspx file from the visual studio template, it has AutoEventWireup="true". This leads to event handlers being registered twice and run twice.
Is there an easy way to cause the compile, build or other post build step to fail when the directives are set "wrong".
I'm using Visual Studio 2010 and TeamCity. I'm open to running any technology as a postbuild step.
You could precompile your site. Precompiling involves compiling the aspx and ascx files aswell as the .cs. It will make your site faster and it ensures things hook up a bit better, the downside is you cant change the aspx or ascx after you have compiled them.
http://www.dotnetperls.com/precompiled
This SO page describes a couple of ways of doing it
Compile Views in ASP.NET MVC
You could try integrating StyleCop with TeamCity, and create a custom StyleCop rule that checks for this. Not sure how difficult it would be, but it's what comes to mind. See this question about using StyleCop with TeamCity.
Also, as suggested by Erix, update your templates to prevent this from being the default behavior.

Best way to manage generated code in an automated build?

In my automated NAnt build we have a step that generates a lot of code off of the database (using SubSonic) and the code is separated into folders that match the schema name in the database. For example:
/generated-code
/dbo
SomeTable.cs
OtherTable.cs
/abc
Customer.cs
Order.cs
The schema names are there to isolate the generated classes that an app will need. For example, there is an ABC app, that will pull in the generated code from this central folder. I'm doing that on a pre-build event, like this:
del /F /Q $(ProjectDir)Entities\generated*.cs
copy $(ProjectDir)....\generated-code\abc*.cs $(ProjectDir)Entities\generated*.cs
So on every build, the Nant script runs the generator which puts all the code into a central holding place, then it kicks off the solution build... which includes pre-build events for each of the projects that need their generated classes.
So here's the friction I'm seeing:
1) Each new app needs to setup this pre-build event. It kind of sucks to have to do this.
2) In our build server we don't generate code, so I actually have an IF $(ConfigurationName) == "Debug" before each of those commands, so it doens't happen for release builds
3) Sometimes the commands fail, which fails our local build. It will fail if:
- there is no generated code yet (just setting up a new project, no database yet)
- there is no existing code in the directory (first build)
usually these are minor fixes and we've just hacked our way to getting a new project or a new machine up and running with the build, but it's preventing me from my 1-click-build Nirvana.
So I'd like to hear suggestions on how to improve this where it's a bit more durable. Maybe move the copying of the code into the application folders into the NAnt script? This seems kind of backwards to me, but I'm willing to listen to arguments for it.
OK, fire away :)
How often does your DB schema change? Wouldn't it be possible to generate the database-related files on demand (e.g. when the schema changes) and then check them into your code repository?
If your database schema doesn't change, you can also package the compiled *.cs classes and distribute the archive to other projects.
We have two projects in our solution that are built completely out of generated code. Basically, we run the code generator .exe as a post-build step for another project and along with generating the code, it automates the active instance of visual studio to make sure that the generated project is in the solution, that it has all of the generated code files, and that they are checked out/added to TFS as necessary.
It very rarely flakes out during the VS automation stage, and we have to run it "by hand" but that's usually only if you have several instances of VS open with >1 instance of the solution open and it can't figure out which one it's supposed to automate.
Our solution and process are such that the generation should always be done and correct before our auto-build gets to it, so this approach might not work for you.
Yeah I'd like to take VS out of the equation so that a build from VS is just simply compiling the code and references.
I can manage the NAnt script... I'm just wondering if people have advice around having 1 NAnt script, or possibly one for each project which can push the code into the projects rather than being pulled.
This does mean that you have to opt-in to generate code.

Resources