My site works on mono 2.10 and I'm nearly done on a brand new server upgrading to mono 3.2.x.
It works using XSP4, the ServiceStack Razor views render correctly. (And it fixes a lot of artefacts in 2.10)
When I set the site to use nginx + Fast CGI (4) however I get a HttpCompileException, caused by:
The predefined type `System.Collections.Generic.IReadOnlyList' is defined multiple times. Using definition from `mscorlib.dll'
Remember this works fine with xsp4 so I think it needs some setting to tie it to one .Net instance, maybe it's confused between .net 4.0 and .net 4.5? Any suggestions on how I can force it to use only one of these?
Note: I installed from git using latest (3.2.7), as the 3.2.5 release would crash. I'm using a clean Amazon EC2 Ubuntu 12.04 64bit. It didn't have mono on it before, and when I tried 3.2.5 it was another now deleted instance.
This is largely the same error as: RazorEngine on Mono - TemplateCompilationException thrown
But I had no other version installed. The build process added others which have since been deleted to no effect. All instances of mscorlib are here:
/usr/lib/mono/2.0/mscorlib.dll
/usr/lib/mono/4.5/mscorlib.dll
/usr/lib/mono/4.0/mscorlib.dll
I found out what the problem is and was able to solve it.
The culprit are these files:
https://github.com/mono/xsp/tree/master/src/Mono.WebServer.FastCgi/Compatibility
For some reason, they added these compaibility classes that are compiled to a NET 4.0 target (which does not have the IReadOnlyList class), but when we run the fastcgi-mono-server4, it runs under the 4.5 runtime, which do have a IReadOnlyList class and therefore generates the Razor HttpCompile error.
The solution was adding these 2 parameters -d:NET_4_5 -sdk:4.5 to the Makefile.in of the FastCGI source project:
#NET_4_0_TRUE# $(DMCS) -d:NET_2_0 -d:NET_4_0 -d:NET_4_5 -sdk:4.5 $(MCSFLAGS) $(references4) /out:$# \
Then I recompiled and reinstalled with ./configure, make, make install and the Razor compile error was gone for good.
If you don't want to go through all this trouble, I'd recommend sticking to the latest released version of the xsp project, which didn't have these Compatibility classes.
Related
Steps to reproduce a problem:
Download and install dotnet core 3.0
Create a new project: dotnet new webapp -n MyApp
Run app dotnet run
Navigate to http://localhost:5000/Privacy
Edit Privacy page MyApp\Pages\Privacy.cshtml
Refresh
The changes do not get picked up by the toolkit and old page is rendered.
Same flow for dotnet core 2.2 (freshly installed) results in an updated page.
Is there a flag, which needs to be set somewhere within config to get autodetect working for 3.0 or is this a bug?
Use the dotnet CLI command to watch run your project:
dotnet watch run
Optionally you can watch run without hot reload enabled:
dotnet watch run --no-hot-reload
Add this instruction to the project file [ProjectName].csproj:
<ItemGroup>
<!-- extends watching group to include *.cshtml and *.razor files -->
<Watch Include="**\*.cshtml;*.razor;*.js;*.css" Exclude="**\obj\**\*;bin\**\*" />
</ItemGroup>
For further information see Microsoft DotNet 5.0 Documentation.
While searching the root cause of that issue i came accross with that SO question. To resolve that issue you need to add Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation NuGet package to your project and modify your Startup.cs like below.
Inside ConfigureServices method of Startup.cs
For ASP.NET Core MVC:
IMvcBuilder mvc = services.AddControllersWithViews();
mvc.AddRazorRuntimeCompilation();
For ASP.NET Core Razor Pages:
IMvcBuilder mvc = services.AddRazorPages();
mvc.AddRazorRuntimeCompilation();
PS: Do not forget to use this feature 'dotnet-watch' for development environment only since it does not make sense for production environment for most cases.
Source: https://learn.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio
2021 UPDATE (Better Solution): You do not need to execute AddRazorRuntimeCompilation method in Startup.cs. You can keep this feature running by adding a value to projects debug configuration.
Please add new Environment variable to Project Properties > Debug > Environment variables
Name: ASPNETCORE_HOSTINGSTARTUPASSEMBLIES
Value: Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
I'm not entirely sure this is the same issue, but ASP.NET Core 2.2 introduced an In Process IIS hosting model. This provides a lot of performance benefits in a production environment, but basically negates one of ASP.NET Core's most useful development features: automatic updates. If you're using the In Process model in development, you'll need to build after code changes, just like with older ASP.NET MVC sites. You can switch the hosting model back to the Out of Process model (the old way) either by going to your project properties or editing your csproj. In properties, there's a dropdown now on the Debug tab, which corresponds to the <AspNetCoreHostingModel> tag in the csproj.
UPDATE
For what it's worth, I've actually seen this behavior to be somewhat random actually. Some changes for me seem to kick off an automatic build like they used to, while other changes don't show up unless I manually build. There doesn't seem to be a lot of rhyme or reason to which changes required what either. It's possible that the tooling for this isn't quite there yet, and a future update to Visual Studio may make the In Process model behave consistently like the Out of Process model did with code changes in development. All I know is that switching to Out of Process definitely resolves all issues with this, so it's related to the In Process model in some way.
I followed Building From Source https://github.com/primefaces/primefaces/wiki/Building-From-Source instructions. Building the SNAPSHOT version project from command works well.
However, importing it into eclipse using the Existing Maven Projects wizard gives me a lot of errors in the Problems view. I fixed the lifecycle mappings by setting all to ignore.
I realized the generated source code in the target/generated-sources/maven-jsf-plugin directory but it was not picked up by the m2e plugins as a source folder automatically. So I included it into the eclipse build path manually. But then again, many compile errors show up in the generated code.
Does anybody use eclipse as IDE for primefaces development? How do you setup the eclipse project to develop primefaces?
The eclipse project uses Java Compiler compliance level 1.5 derived from the pom.xml maven-compiler-plugin settings. Setting the Java Compiler compliance level to 1.6 solved the issue for me.
Context
In asp.net 5 vNext MVC6, Web.config is gone, in favor of json file as config. However, in my web.config, I have settings of WCF clients, trace listeners of System.Diagnostics and Essential.Diagnostics, and these components (WCF clients and trace listeners apparently could not read json at startup). So in vNext Microsoft has abandoned System.Configuration apparently.
Question
Are there some migration path so I don't have to totally rewrite in order to make these components read config info at startup?
Short answer: It works fine in ASP.NET Core MVC on .NET Framework (4.5.1+), put your settings in app.config, but doesn't work in ASP.NET Core MVC on .NET Core.
Longer answer:
ASP.NET Core can run on both .NET Framework and .NET Core, so I guess the migration path is to continue using .NET Framework for now.
For System.Diagnostics, and Essential.Diagnostics (which I contribute to), I have been able to at least get a demo of this working in ASP.NET Core running on .NET Framework (not .NET Core).
In the .NET Framework, TraceSource, etc still load from the config. In an ASP.NET Framework project there will be an app.config file (not web.config) where you need to put the configuration sections.
Note: Just Building (Debug > Start new instance) does not update the .exe.config file in the bin directory; you need to do a Clean or Rebuild, and then Debug (or delete the output bin folder).
You can write to TraceSource either directly (for legacy code), or via the new Microsoft.Extensions.Logging, with the Microsoft.Extensions.Logging.TraceSource provider configured. (The new interface includes some nice hierarchical support features.)
Either way, it will load and write to the configured TraceSource, which can output to system TraceListeners.
You can also configure additional listeners from Essential.Diagnostics (although the RollingFileTraceListener wasn't correctly handling the {AppData} token in the filename, so I had to hard code the path to C:\Temp\Logs).
The above also works in a console app (simpler), with the .NET Framework 4.5.1 and above.
There is some example code in Essential.Diagnostics: https://essentialdiagnostics.codeplex.com/SourceControl/latest#Examples/TestAspNetCoreOnNetFx/Controllers/HomeController.cs
I suspect it may be similar with WCF: the .NET Framework version should continue to work, using app.config, but the .NET Core implementation may be a shell only.
On .NET Core:
Note that Essential.Diagnostics will not work on .NET Core (it doesn't support it yet, as at Feb 2017), and most system TraceListener classes are also not supported.
The only one that is is the TextWriterTraceListener, which I have got working with a manually created TraceSource, however from looking at the .NET Core source code, I don't think there is a way for TraceSource to automatically load configuration yet.
I get the following error when I try to build my first GPU Program. Any suggestions what might be going wrong?
Error 1 error MSB4062: The "Nvda.Build.CudaTasks.SanitizePaths" task
could not be loaded from the assembly C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\Nvda.Build.CudaTasks.dll.
Could not load file or assembly 'file:///C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\Nvda.Build.CudaTasks.dll'
or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements
Microsoft.Build.Framework.ITask. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA
3.2.targets 70 4 gpu
I have faced with this problem. So many searching on internet but I could not find anything. At last I recognize that I closed Microsoft .NET Framework 3.5.1 features on Windows Features section in Control Panel.
to turn on Microsoft .Net Framework 3.5.1, you can easily follow these instructions;
http://www.sevenforums.com/tutorials/5023-windows-features-turn-off.html.
I hope this solution will help you !
I've come across this problem after upgrading my system to windows 10. It turns out that I have to reinstall Visual Studio because some dependent dlls have been moved to Windows.old folder.
I had this same error when I was compiling on a remote server. I think it was because I was logged in using Remote Desktop (RDP). When I logged in using VNC and compiled, the error no longer happened.
Note that it's impossible to even install the CUDA Toolkit via RDP, so this is unlikely to happen, unless you regularly use both methods to connect to a server.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.