Error using NSass - asp.net-mvc

I've setup NSass from NuGet. It's a managed wrapper around libsass and has a HTTP handler that does on-the-fly compilation of .scss files to CSS.
The problem is that the handler throws the following arcane InvalidOperationException:
Found NSass.Wrapper.proxy.dll which cannot exist. Must instead have
NSass.Wrapper.x86.dll and NSass.Wrapper.x64.dll. Check your build
settings.
I can see that the code and message is copy-pasted from some trickery found here (see bottom):
Load x64 or a x86 DLL depending upon the platform?
So my guess was that my web project needed to target x64 specifically, maybe to force a decision on the unmanaged library being used.
That just ends with a BadImageFormatException maybe due to IIS Express being 32-bit which I've seen being a PITA with Oracle dependencies - I gave up then, too.

I think, due to the unmanaged library, AnyCpu cannot be used for the project, instead you must pick a target processing platform.
For me that's 64-bit but IIS Express is a 32-bit process. I recall having similar issues with unmanaged references, bitness and IIS Express (32) vs. production (64) with Oracle libraries.
So when IIS Express tries to load the x64-targeted website assembly, it blows up.
I am now looking into a compile time CSS compilation, rather than runtime, using Web Workbench or something.

I got the same issue, and the reason for it was that the NSass.Wrapper.XXX.dll files were not copied into the output directory.

Related

Need DevEnv on Jenkins machine without installing VS - require api-ms-win-core-heap-l2-1-0.dll

I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio.
Devenv.exe is required for a MSI package.
I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll
This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.
Where can I find this file?
Are there other ways to build a vdproj without Visual Studio?
Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?
WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.
Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:
An API Set is a strong name for a list of Win32 APIs. The convention
for assigning a strong name to an API Set is to use what appears to be
a dll name. But the purpose of an API Set is to provide architectural
separation between the API Set's name and its associated host DLL
implementation for improved portability of your app, so you should
think of an API Set's name as just a unique character string, and not
as a dll name. For delay load, you use the name of the API Set.
API Sets rely on operating system support in the library loader to
effectively introduce a namespace redirection component into the
library binding process. Subject to various inputs, including the API
Set name and the binding (import) context, the library loader performs
a runtime redirection of the reference to a target host binary that
houses the appropriate implementation of the API Set.
The decoupling between implementation and interface contracts provided
by API Sets offers many engineering advantages, but can also
potentially reduce the number of DLLs loaded in a process.
On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.
Nice article on the technical aspects of this new API-Set feature.
Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).
WiX Quick Start: Here are some of the best links that I have found over time for WiX:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.

(Delphi 7) I can't run my program executable on non-Delphi PCs?

I was making a Delphi application, and wanted to test it on another PC to see if everything was working properly. I compiled and built the executable file, of course and I transfered all of the files from the Project folder to the other PC. When I launched the .exe file on the PC, nothing would happen. I then ticked the "Build with runtime packages" option in Project Options:
This made the .exe go from around 300 KBs to around 30 KBs, but now, instead of being able to launch the application on another (non-Delphi) PC, that PC got an error saying it was missing various files required to open the .exe .
I sent the same thing to various friends and all reported the same problem.
My application is a rather simple lottery prototype application, so I don't understand why I'm having trouble opening it on other PCs. Are there other special options I need to enable for this to work?
When you use runtime packages, you need to distribute those packages. These are the .bpl files that your program links to. It will be a subset of the packages listed in the runtime packages edit box in your screenshot. You should just list the packages that you use.
The net result of doing this is that the total amount that you will have to distribute is much greater than a single monolithic executable. Because in a monolithic executable the unused code can be stripped. If you want to minimize the size of your program, and make life simple, do not use runtime packages.
It would be worthwhile reading Embarcadero's documentation:
Working with Packages and Components
Solve the first problem.
Using Runtime Packages will not solve the problem of your EXE not running on certain PC's. All it does is increase the complexity of deploying your application (as you have found).
Unless you need Runtime Packages for other, specific reasons, then you are far, far better off NOT using them, especially if you do not understand them (which based on the way you describe having discovered them does appear to be the case, if we're being honest).
Concentrate on finding out why your application does not run as a single, stand-alone EXE.
With all of the problems involving runtime packages your EXE is currently not even reaching the point of running your application code, and this may be where your original problem lies. Which means that once you have solved all the issues created by Runtime Packages, you will stil be left with an EXE which does not run. i.e. your original problem.
What does your application do when it starts ? Does it attempt to load files from any specific locations ? What are those locations ? What are the files ? Are you using any third party libraries which may expect DLL's to be present or other external files ? Are you trying to read or write settings to the registry or any external files (INI files etc).
What is the OS you are trying to run on ? This can be a very significant question for applications compiled with older Delphi versions. Have you tried configuring the EXE to run in Compatibility Mode for older versions of Windows ? (something that you do in Windows itself, not when compiling the EXE).
These are the questions you should be focussing on. Not runtime packages.
Gday,
A small tool that's been around for a while to help you with this is Dependency Walker. You can find it at http://www.dependencywalker.com. It's helped me out on more than one occasion. This will tell you what files (usually BPLs as stated in the other responses) need to be sent with your EXE.
Also look at NSIS to create a simple installer, and put your EXE and supporting BPLs and any other files in the same directory.

Precompiling MVC ASP.NET application via publish, Are the resultant files IL Code or Native Images?

Just wanted to check whether the precompiled files from "publish" are IL or Native. The file extension are .compiled for the views, and dlls for others.
I have seen some comment that imply that one of the advantages for doing this is to eliminate startup lag due to JIT, but this implies that they are native, but I am not sure.
I have chosed "no merging" of files for my first attempt.
Confirmation appreciated.
Thanks.
EDIT
Is there any potential difference if I select x86, or "mixed platforms" or "any cpu". The latter 2 might imply IL code whereas x86 could be native. I am targetting a 32bit Azure Websites instance. I am trying to get rid of the warmup period issue.
It is IL. You can confirm it by running CorFlags.exe. The CorFlags section of the header of a portable executable image will indicate whether its 32bit or AnyCPU etc. Another utility that comes in handy is DUMPBIN.EXE.
Even if you precompile your web applications, there's going to be an initial hit when you access the website. That process is described here. Its a tad dated, but much of it still applies. But the hit with a precompiled website is going to be substantially less than a non-precompiled website.
When compiling, select "Any CPU" and control whether its a 32bit or 64bit application via IIS, Azure or the hosting environment. Let the framework do what the framework does best.

Why does my MVC4 project not have debug and release folders under the bin folder?

When I build my app, I just get a single bin folder, with all files in it, versus the usual bin\debug and bin\release folders. Why is this?
Because the website can be run by IIS ( and the various flavours of... ) in the location you built.
IIS expects the assemblies in the bin folder ( it's hard wired in the AppDomain setup ) so the web project type compile to this location.
For an interview, i was put across with this question. One of the link could be this which answers in brief .
The above link will give you the statement as below:-
Release Mode
When an assembly is built in release mode, the compiler performs all
available optimisations to ensure that the outputted executables and
libraries execute as efficiently as possible. This mode should be used
for completed and tested software that is to be released to end-users.
The drawback of release mode is that whilst the generated code is
usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is
compiled in debug mode, additional symbolic information is embedded
and the code is not optimised. This means that the output of the
compiler is generally larger, slower and less efficient. However, a
debugger can be attached to the running program to allow the code to
be stepped through whilst monitoring the values of internal variables.
[Update] After little google i came across similar question- "Confused about Release/Debug folders in Visual Studio 2010" with same answer which i have quoted above.
Also, please look into why-have-separate-debug-and-release-folders-in-visual-studio. #riko and other members of Stackoverflow have answered quiet well..
This behavior is not specific to MVC4. In fact it is consistent with so-called "classic" ASP.Net, both Web Site projects and Web Applications.
The distinction between release and debug modes in ASP.Net is that Release builds need to be Published.

rtl90.bpl was not found, how do I include it in my Delphi 2005 win 32bit app?

The software that I have found myself supporting, from time to time fails to run on different PC's. Generally they are new Win7 installs.
The error message is "this application failed to start because rtl90.bpl was not found..."
To rectify the problem I have out PC Support copy the rtl90.bpl file to the users system32 directory, however i would like to ensure this error no longer occurs.
I have googled and found the followling link rtl90.bpl problem
My question is this:
The option to "Build with runtime packages" is already selected under the Project options for this program, and does not appear to make any difference to the users getting the problem.
Do I have to specifically Add the missing rtl90.bpl file to the project?
Please note that I know very little about delphi programming.
Since you are marked the option Build with runtime packages in your project, the final exe will require be deployed with some additional bpl files. To avoid that dependencies you must uncheck that option y build your project. Now your exe wil be bigger but without dependences.
That package is a runtime package containing the VCL. You presumably also need to deploy rtl90.bpl for the RTL and possibly some others. By enabling runtime packages you are promising to deploy those packages where the executable can find them.
You have 3 main options:
Deploy the packages to a location that is contained in the PATH variable. Usually this means modifying PATH. You should never write to the system directory. It is owned by the system and you should respect that.
Deploy the packages to the same directory as the executable file.
Disable runtime packages and therefore build a single self-contained executable. The RTL/VCL code will be statically linked into your executable.
Option 1 is poor in my view. Relying on the PATH variable and the ability to modify it is fragile. Option 2 works but seems rather pointless in comparison with option 3. You deploy more files and larger files when you choose 2, so why choose it.
In summary I recommend option 3. Statically link all RTL/VCL code into your executable.
The only situation where option 2 wins, in my view, is when you have multiple related executables that are all deployed to the same directory. In that situation sharing the RTL/VCL code can make sense.

Resources