I upgraded a Windows Server 2016 to Windows Server 2022.
The upgrade defaulted to a fresh install in which no setting, programs and customizations were retained.
After the upgrade I pointed IIS's Default Website to the directory that was originally the IIS root on Win 2016.
Modules were not carried forward in the upgrade. When I attempt to Add Managed Module it returns the following error:
There was an error while performing this operation.
Details:
Cannot execute a program. The command being executed was 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe' /noconfig /fullpaths
#"C:Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\<number>\<number>.cmdline".
On the original computer (which was backed up) IIS's managed modules do not return an error. I also add that I can access the original computer if there is a need.
Is there a way I can reset this functionality or correct this error?
--------------- Update
At the Server level the options works well. The problem only appears to be at the website level.
--------------- Update
The error is thrown when I add a C# program in a directory under the website.
As a POC I added a simple "Hello World" program and the Add Managed Module returns the error I shared.
I can confirm that csc.exe is present in the directory.
Any ideas how to resolve this issue? It seems (not sure) that the problem is happening because the code is failing to compile.
Any ideas on how to resolve this would be appreciated.
Related
When I try to register a Visual FoxPro DLL via an administrator command prompt:
C:\Windows\SysWOW64>regsvr32 C:\_temp\my.dll
on machines that are not mine I get the following error:
The module "c:\_temp\my.DLL" was loaded but the call to
DllRegisterServer failed with error code 0x80004005.
For more information about this problem, search online using the error
code as a search term.
I am able to register it on mine. How do I get more info as to why it is failing?
Can I use my machine where it does register to back into why it doesn't register on other machines?
I've manually copied MSVCR70.dll into the %systemroot%\SysWOW64 directory on the machine that it won't register on.
I've reviewed the dependencies with https://github.com/lucasg/Dependencies and everything looks good.
I have typically found and associated 0x80004005 with permissions. Did you try to run the DOS prompt AS ADMINISTRATOR?
Also, VFP is ONLY a 32-bit application/dll, it was never 64-bit support, so you probably need the files in System32, not SysWow64.
Permissions might also need to be confirmed for those USING the dll. Ex: you install with admin permissions to drive
C:\SomePath\YourVFP.dll
Make sure the end-user has permissions to this path/file as well.
Aside from the above points... Do you have the VFP SOURCE code / project to build the DLL?
Based upon the comment from Tamar, I searched the registry for this DLL on a machine where I could register it and I found {CLSID}\Foxruntime\VFP7R.DLL.
I installed the VFP 7 Runtime from here (github.com/VFPX/VFPRuntimeInstallers) and I was able to register the DLL 😊
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: The compiler failed with error code -2146232576.
Clean and Rebuild your solution (under Build menu). If it gives you any compilation errors, correct them and build it again. That worked for me.
Edit 3/12/18
It seems like you have read, or possibly write, locks on one or more files. Close the studio and verify that the source code repository don't have orphaned read/write locks. Also verify that any directories used for compilations don't have read locks. There used to be a weird Temporary ASP.NET-folder that was prone to locking files in the good old days.
Previous response
These are a few things that come to mind in my experience. I am assuming the deployment machine is a Windows Server of sorts.
Check the expected .NET version by checking project properties in Visual Studio (or the Project-files if another editor is used).
Compare with the installed version of .NET of the deployment machine. Framework on the deployment machine should equal to or greater than .
Verify the chosen app pool is running the expected version (or change it) and recycle it.
Make sure all the necessary assembly files (.DLLs) have been included on the deployment machine. A quick look into the BIN or DEBUG folder usually tells the story, but will generally also contains a whole lot more stuff. Sometimes too many assembly files removed during optimisation of the build.
A little bit of information about deployment OS and .NET versions would help.
I got the following error while running the vb6 project in windows 7. I was search in google. I can't find the exact solution. Please help me to fix this issues.
The component CCrpDtp.ocx or one of its dependencies not correctly registered.a file is missing or invalid
The most obvious thing is to check to see if you have the ccrpdtp.ocx file installed and registered on your machine.
If you do not, go to the Common Controls Replacement Project site and download ccrpdtp6.zip.
The file contains the control and a dll dependency, both of which need to be installed somewhere on your machine. There's also a readme file which explains that you have to use regsvr32 to register the ocx.
I have an year or so old application which uses Expression Encoder 3 to generate thumbnails. Few of the users are complaining that they are receiving the following exception:
Could not load file or assembly 'Microsoft.Expression.Encoder.Utilities.dll' or one of its dependencies. This application has failed to start because the application configuration is incorrect.
The application contains in itself the required EE3 assemblies in the setup, so as such installation of Expression Encoder is not required.
All these crashes started to occur after the application was upgraded to .net 4.
Any clues on what might be happening?
[EDIT] Was able to reproduce the issue on one of our local systems. We did a clean install of Windows XP. Installed .net 4 and then our app. It crashed with the same exception. We could fix the issue by installing .net 3.5!
I was quick to point fingers at .net 4 backward compatibility.
So the question remains: any clues on what might be happening?
According to this question this seems to be an issue with EE3 itself in that it requires EE to be installed (via the installer) to work properly.
Sadly this also seems to be the case for EE4, according to this thread, due to a codec licence issue.
Sorry :/
Have you looked at MediaFoundation? it might serve as an alternative, although ive never used it myself.
I had similar problems, where it wasn't working on a Windows7 64-bit server.
Here's some things I've learnt:
You must modify your project's build settings so it has a target platform of "x86".
You must ensure that the "Desktop Experience" feature is enabled on the target machine. See this blog.
I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error
"Strong name validation failed for assembly.exe" .....
But none of my stuff is strong named! I saw this post here: Strong Name Validation Failed and tried running it through 'sn.exe -Vr merged.exe' but that gives me this error:
"merged.exe does not represent a strongly named assembly"
Has anyone else had this problem before? How do I fix it?
UPDATE:
I'm starting to feel like Strong name validation isn't the real problem here. I'm building against .NET v1.1 and running on a machine where that is the only .NET version installed (happens to be Windows 2003). The merged executable appears to die with that error on every Windows 2003 machine I try, but if I try to run it on a more modern OS (Vista) it at least starts, but that's not really a good test since the environment isn't fit for a real test.
I have verified that my app.config has the correct settings (specifying required and supported runtime version of v1.1.4322)
I use the /targetplatform:v1.1 option when running my assemblies through ILMerge.
ILMerge is definitely causing the problem (i.e. it works fine before I merge), I just don't know how to fix it.
I had to find and download a very old version of ILMerge (v1.1) in order for my merged binary to work; there must be a bug in the way the current ILMerge application builds .NET 1.1 assemblies. Thankfully we had one internally because I would probably have never found it online.