I'm moving some legacy sites built using the classic ASP.NET (i.e. non AJAX) Telerik RadControls. I'm running into the issue that it can't find the Telerik.WebControls dll.
It runs on the server it is currently on, even though I can't find that DLL anywhere on that server. Could it be installed in some other way or does anyone know where I can find this legacy assembly?
Thanks!
You may want to check in the Global Assembly Cache on the server. It's possible that they installed it globally for all applications.
The location would likely be C:\Windows\assembly for an older version of .NET (pre 4.0)
If you find it there, then that means it was installed globally. It's likely sitting somewhere on the server and you could potentially do a search on the entire file system.
I found this post which also talks about extracting a DLL from the GAC How to extract an assembly from the GAC?
Related
The best way to include System.Net.Http.Formatting might be through nuget. But when a developer sees it in the default Assemblies section in reference manager then they just add it, expecting all developers to have it installed by default. But to our surprise, some developer machines did not have this dll.
All developers have the correct folder where this dlls is found
"C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\"
Some developers just have XML files and others have dlls in it, even though the file names are the same.
Why are dlls missing in some machines?
Sometimes it is really an issue while finding the missing dlls. Better approach is to clean the nuget cache and folder both and restoring nuget packages again would resolve this issue.
System.Net.Http.Formatting mystery resolved
System.Net.Http.Formatting won't be installed by default along with asp.net. If it appeared in one developer machine, then it could be because some other projects in the VS might have used a nuget to pull it in. This developer without knowing this gives a manual reference to this dll in a new/different project. To him/her everything works fine.
When another/new developer comes and tries to do the same in his/her machine, before reaching this particular project(which pulled in System.Net.Http.Formatting through nuget), the developer gets error(from the manually entered dll project by the previous developer mentioned above). That explains why the dll is missing in his/her machine.
But why is XML file present then?
Becuase the package folder was stored in tfs/git from the first developer machine(who successfully had the dll through nuget). And tfs/git ignored the dll when checked-in.
There has been a lot of talk about the C# compiler Roslyn on StackOverflow and the internet in general. A lot of people ask what and why with Roslyn, while others ask how to get rid of it.
My question pertains to the latter question. As quoted from Kemal Kefeli from here, but frequently iterated verbatim by dozens more (e.g. another example of iteration), in order to remove Roslyn:
When you create a new web project, two NuGet packages automatically added to your project. If you remove them, your problem should be solved. Package names are: "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers".
This approach, however, does not work if you are using the C# 6 features that Roslyn offers. By removing these two nugget packages, you give up any chance of using these features.
My question is, how do you compiler everything with Roslyn, but avoid having any compiler-at-runtime actions occurring and most importantly, the csc.exe, vbc.exe, and VBCSCompiler.exe from being placed in the final release version (in the Roslyn folder).
I am porting over StackOverflow's Opserver into a piece of software. The software allows users to host embedded web servers and web pages from within it. However, the software is very picky about what it allows to be uploaded and executables, like those found in the Roslyn folder, are not allowed to be uploaded and executed at runtime due to security reasons.
Opserver relies on C# 6 features, because if I remove those two NuGet packages, errors sprout up in compile-generated files. But, if I more simply revert to compile strictly with the C#5.0 compiler, then we see this clearly:
If I leave the NuGet packages present and uncheck allow precompiled site to be updatable when publishing, in order to disallow Roslyn with compiling files at runtime as followed by Rutix's comment from here:
Keep in mind that removing these packages [as told by Kemal Kefeli] will break the use of C# 6 features. This could be solved by unchecking "Allow precompiled site to be updatable" which pre-compiles the views ect.
It still generates the executables and the associated DLLs in the Roslyn folder, however significantly less DLLs. How can I possibly remove the Roslyn dependency at runtime and therefore the executables from the outputted version and strictly compile everything at compile-time?
In fully precompiled ASP.NET project ("allow precompiled site to be updatable" disabled) there is no need for compiler to be deployed with app IMHO.
I'm using Roslyn in my .NET 4.6 ASP.NET app (mix of Web Forms and MVC) and precompiled app works just fine after removing Roslyn folder\files from published site...
UPDATE: After a while a found only place where absence of Roslyn in deployment package is the problem a that's accessing ASMX (old style ASP.NET SOAP web service) in browser - "help" page for ASMX is apparently build at runtime even for fully precompiled ASP.NET application and it throws exception (although WS itself runs OK)
Am I doing this right? I've got many, many separate ASP.NET webforms projects which reference the same main library which contains many tool methods. When I change something in that library, I don't know of a way to make sure that these projects get the updated version of the library. Does auto-refresh detect changes in references even if you don't open the project in Visual Studio? Or does IIS know when a reference has changed and will recompile the project?
Assuming the DLL file is binary compatible (changing an existing method signature is the easiest way to break compatibility) all it comes down is that the newest DLL is in the \bin\ folder. If the site is running it would need to be restarted to pick up the DLL being replaced.
If this is a project reference in your solution, building just does all of this for you.
If this project is outside of your solution, you really should look into using Nuget to distribute this shared project. Even if you only distribute it to yourself. You do not need to host the package publicly on nuget.org
I don't have access to an IIS server but I am told that the site is configured to run with version 1.1 of the .NET Framework. When I use Telerik JustDecompile I see the following.
The "NET 1" seems to suggest that the 2 dlls are compiled against version 1.1 of the FW. Does the "ANY" next to the website dll "GLSS" indicate that the site can run against any version ofthe .NET FW that is installed on the web server?
In preparation for an upgrade to 2.0, I have asked the web admins to change the site configuration to version 2.0 of the FW and I was surprised that the site, which I considered to be running 1.1 code, still worked. Should I be surprised?
Is this just a simple example of backward compatability and that the site could be configured to use any version of the framework provided that it was equal to or higher than the version that the code was compiled to use?
when I look at the property pages for the projects in the solution, I was surprised that, for the website project only, I was unable to locate where one sets the version of the FW which you want to compile against. I was able to locate it for the referenced projects.
Can you help me better understand the relationship between the version of teh FW that a site is configured and the versions that the assemblies are compiled against?
You should not be surprised, .NET was always backward compatible in a sense that assemblies compiled against a version of the runtime are supposed to run against a newer version of the runtime.
There are of course subtle issues where things are not backward compatible, starting from subtle semantic differences and ending with changes at the object contract level (where the expected method/class just does not exists anymore) but in general these problems depend on the complexity of your application. It is safe to assume that simple applications should just work with no issues.
The number of the runtime the assembly has been complied against is a part of the assembly's metadata, it can be read with reflection. Thus, at runtime, you have at least two possible versions of the runtime - the one the assembly has been compiled against and the current version of the runtime which executes your code.
Hi guys I got some code here thats buggin me.
ive managed to create a page and get it working on local host, but when i publish this to go live and nav to the web page it comes up with this error.
Could not load file or assembly 'DevExpress.Web.v11.1,
Version=11.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a' or
one of its dependencies. The system cannot find the file specified.
(E:\web\shafteccom0\htdocs\Calendar\web.config line 44).
Ive tried adding all the references, and i mean all of the dev express ones, including ones i dont even need.
my project is a web project using visual studio 10, asp.net,C# & .Net version 3.5
ive also tried changing the .net version to 2.0, 3.0 and 4.0 but no luck.
If you need my code let me know and ill edit this.
Many thanks
That error means that the library that your application is looking for does not exist on the server you are deploying it to (or it cannot load it with the variables provided). Does the live server have the VS2010 references installed to it?
Just making sure: Are you sure your references set to "CopyLocal"?
I think DevEx installs it's assemblies in the GAC, so your local copy may be working but not when you deploy. Have you tried looking in the bin on the publish location to see if they are actually there?