I am using aspnet_complier command for building website, first time it is compiling complete website i.e all pages, but after modification on the site, it is again compiling all the pages. It should compile only that pages that have been changed or modified.
And other things are
1) How can i speed up the aspnet_compiler ?
2) how can i exclude warning from the output ?
Please suggest on the same.
According to the documentation, "You can also recompile an application in place after adding new source files to it. The tool compiles only the new or changed files unless you include the -c option".
Unfortunately, there doesn't appear to be an option to hide warnings.
Speed up the process by making sure the machine where you run it is appropriately powered. eg. an SSD disk should probably help.
Related
I am new to nopcommerce and I am developing a plug-in in it.
I have partially created my plug-in and meanwhile i have found that if i change anything in plug-in's code (View, model, controller, services, etc.) then i have to UNINSTALL my plug-in and then INSTALL to see the changes.
It is really tedious task to do.
Is there any other alternative way to see changes especially for designing view where we just need to set our designing.
If it is possible to see changes by just reloading it in browser then it will be great for all.
Please reply if anyone has any idea about that.
All answers are accepted.
Thanks in advance.
As far as I know all installed plugins are cached into memory so just overwrite .dll in Plugins folder and you can either
Restart your application with IIS/WebMatrix
Go to Admin > Configuration > Plugins and in top-right corner of the plugins view hit "Reload list of plugins"
"Restart application" or maybe even "Clear cache" in top-right corner of the admin page may work too. Try it out.
You should clean the solution and then build plugins after making changes to the code of the your plugin.
I have a batch-file that I run each time I want to deploy changes to my plugin on my local IIS. It may be overkill, but it works. I keep it on my desktop. When I want to test changes, I right-click and "Run as Administrator".
#ECHO OFF
ECHO Stopping IIS
iisreset /stop
ECHO Clearing Temporary ASP.Net Files (Server cache)
for /d %%i in ("%systemroot%\Microsoft.Net\Framework\*") do for /d %%j in ("%%i\Temporary ASP.Net Files\*") do RD /q/s "%%j"
for /d %%i in ("%systemroot%\Microsoft.Net\Framework64\*") do for /d %%j in ("%%i\Temporary ASP.Net Files\*") do RD /q/s "%%j"
ECHO Building MyPlugin
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /build Debug "C:\Path_to_Nop_Source\Plugins\MyPlugin\MyPlugin.csproj"
ECHO Deploying MyPlugin
xcopy "C:\Path_to_Nop_Source\Presentation\Nop.Web\Plugins\MyPlugin" "C:\Path_To_WebRoot\Plugins\MyPlugin" /D /Y
ECHO Restarting IIS
iisreset /start
ECHO Done
pause
When I ran into this problem I tried restarting everything starting with the app, then the app pool and even iis. Unfortunately it didn't work. What did work however was rebuilding the site again and copying it over again (mainly all the nop.core.dll, nop.web.dll etc.). I did copy the core dlls of the site the first time around too, but I guess the plugin was copied after those. I think the important part is that the core dlls need to be recompiled so they appear different to iis and cause the already loaded plugins to get unloaded from memory.
I'm quite sure that restarting the whole server would work too, but who would want to do that?
P.S. I was about to ask the same question, because I couldn't find this one while googling (probably because the title is a little too specific). I intended to name mine Plugin not updating after copying a newer version. What lead me to this question was the similar question block that appears when you write a question.
Update: So I discovered that sometimes rebuilding and replacing nop core libraries isn't enough. However in that situation using the "Reload list of plugins" option in admin panel did the trick. Another time I was trying to just use that option and it didn't work until I replaced the core libraries. So to reload a plugin one or both of those steps might be required.
I've been working on a program called RoboJournal for a long time. The next release has full documentation included; Whenever the user presses F1 or clicks the Help item in the RoboJournal program, the help file is displayed in Qt Assistant (way classier than simply opening a browser window to some online documentation).
In its base form, the documentation consists of lots of loose HTML and image files included in the source package. These loose files are supposed to be compiled into a QCH compiled help file and QHC collection file during build time so Qt Assistant can display the documentation properly. On Windows, this was fairly easy because I was able to write a batch script to automate the entire build process (including compiling the documentation and moving the output files to the right place).
On Linux, it's a bit more complicated. True, I could write a Bash or Perl script that compiles the documentation along with the rest of the program but I have no guarantee that the people who will eventually create my app's Debian packages from the source package I give them will use the script. The source package is used to create all the Debian packages so everything has to work flawlessly with the standard build procedure (or the source package is worthless). Therefore, I need the compile process to produce the same results whether the user runs the script or not. As it is now, the user has to build and install the documentation manually. Surely there's some way to automate this.
Is it possible to have Qmake add instructions to run qcollectiongenerator to the makefile (in order to build my application's help files) so it gets handled properly during the "make" step? That way, the QHC and QCH files will be ready to install to their proper locations (in my case, /usr/share/doc/robojournal-0.4.1) along with everything else when the user runs "make install". I've considered compiling the QCH and QHC files in advance and providing them in the source package but the whole point of building from source is to be able to re-create the entire app from its base components.
I know I probably have to add additional instructions to my .PRO file but I’m not sure what or how. I've found something that looks promising (http://www.qtcentre.org/archive/index.php/t-49484.html) and gives me hope that it's possible for Qmake to do what I need but I’m not sure how applicable those instructions are to my situation. Do I have to create a PRI file just for this or can I add the instructions directly to the main project file?
You can try to use the QMAKE_POST_LINK variable:
QMAKE_POST_LINK += build_help.sh
P.S.
I have no guarantee that the people who will eventually create my
app's Debian packages from the source package I give them will use the
script.
I think this is really not your problem :) It's up to them to properly build the package.
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
First off, I will acknowledge that I am aware of another similar thread on the topic of wkhtmltopdf, but it was not similar enough to resolve my issue. Here's the other thread: wkhtmltopdf
Second, I will say that I have successfully used wkhtmltopdf with a Drupal site on a dedicated server that I run, where I installed the libX11 and used the most recent static version of wkhtmltopdf. That's on a CentOS 5 system and it runs nicely.
So, I have another hosting arrangement and I need to get the wkhtmltopdf to work, because it does the most amazing job producing bookmarked PDFs. The PDFs are beautiful.
The hosting is cPanel. I determined that it is on a server that has CentOS 5.5. It is not a problem to drop the static wkhtmltopdf in the print module's lib folder. However, I get the following message back in the Drupal admin status reports page (admin/reports/status).
It says,
"wkhtmltopdf library
The currently selected version of wkhtmltopdf () is not supported. Please update to a newer version."
I have obtained all of the needed .so files for CentOS 5, based on what jockie provided in his answer in the other StackOverflow thread.
Can someone knowledgeable confirm that his list was complete?
The idea of a shell script wrapper seems interesting and appears could be done for Drupal, if the naming of the shell script is called something like "wkhtmltopdf-wrapper.sh".
I have tried to use the shell script code that jockie provided, in a shell script. I did place all of the .so files in a sub-folder called "lib". I confess that I do not know what such things mean, in the script:
export HOME="$PWD"
Can someone interpret for me, what $PWD means?
export LD_LIBRARY_PATH="$PWD/lib/"
I understand that the script is going to get the .so files with that line, yes?
And can someone interpret the following line:
exec $# 2>/dev/null
What I am wondering is, where does the actual pdf get output? I did run the script. It did not throw any errors. However, I did not see a resulting PDF file.
Also, jockie's directions are not totally clear or defined enough. He says, "(some of them are symlinks)" under the list of .so files. Are such lines (in his list), the symlinks?:
lib/libX11.so.6 lib/libX11.so.6.2.0
Or am I mistaken? I was able to get all of them, so I don't know why they would be symlinks. The only thing is, that some of the versions are different. Do I need to delete the following files and make symlinks instead?:
lib/libX11.so.6
lib/libXau.so.6
lib/libxcb.so.1
lib/libXext.so.6
Should the shell script code be written differently, with Drupal in mind?
Thanks for reading and I hope someone can help!
...Finally, if anyone knows of a better solution, please share! Again, I appreciate the help!
...There does not seem to be a way, here on StackOverflow.com to notify jockie to check out this thread. I wish there was a way to write to them or notify them, so that they could clarify for them-self or contribute to this thread as well. If someone knows of a way, please let me know that too!
During our build process we run aspnet_compiler.exe against our websites to make sure that all the late-bound stuff in ASP.NET/MVC actually builds (I know nothing about ASP.NET but am assured this is necessary to prevent finding the failures at runtime).
Our sites are fairly large in size, with a few hundred pages/views/controls/etc. however the time taken seems excessive in the 10-15 minute range (for reference, this is longer than it takes the entire solution with approx 40 projects to compile, and we're only pre-compiling two website projects).
I doubt that hardware is the issue as I'm running on the latest Quad core Intel chip, with 4GB RAM and a WD Velociraptor 10,000rpm hard disk. And part of what's odd is that the EXE doesn't seem to be using much CPU (1-5%) and doesn't seem to be doing an awful lot of I/O either.
So... is this a known issue? Why is it so slow? And is there any way to speed it up?
Note: To clarify a couple of things people have answered about, I am not talking about the compilation of code within Visual Studio. We're using web application projects already, and the speed of compilation of those is not the issue. The problem is the pre-compilation of the site after these projects have already been compiled (see this MSDN page for more details) as part of the dev build script. We are performing in-place pre-compilation, not copying the files to a target directory.
Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/.
In addition to this, make sure that batch compilation is enabled by setting batch attribute to true on the compilation element.
Simply, the aspnet_compiler uses what is effectively a "global compiler lock" whenever it starts pre-compiling any individual aspx page; it is basically only allowed to compile each page sequentially.
There are reasons for this (although I personally disagree with them) - primarily, in order to detect and prevent circular references causing an infinite loop of sorts, as well as ensuring that all dependencies are properly built before the requiring page is compiled, they avoid a lot of "nasty CS issues".
I once started writing a massively-forked version of aspnet_compiler.exe last time I worked at a web company, but got tied up with "real work" and never finished it. Biggest problem is the ASPX pages: the MVC/Razor stuff you can parallelize the HELL out of, but the ASPX parse/compile engine is about 20 levels deep of internal and private classes/methods.
Compiler should generate second code-behind file for every .aspx page, check
During compilation, aspnet_compiler.exe will copy ALL of the web site files to the output directory, including css, js and images.
You'll get better compilation times using Web application project instead of Web site model.
I don't have any specific hot tips for this compiler, but when I have this sort of problem, I run ProcMon to see what the process is doing on the machine, and I run Wireshark to check that it isn't spending ages timing-out some network access to a long-forgotten machine which is referenced in some registry key or environment variable.
Just my 2 cents.
One of the things slowing down ASP.NET views precompilation significantly is the -fixednames command line option for aspnet_compiler.exe. Do not use it especially if you're on Razor/MVC.
When publishing the wep app from Visual Studio make sure you select "Do not merge", and do not select "create separate assembly" cause this is what causes the global lock and slows things down.
More info here https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx