Is there a way to put a digital signature on the Temporary Binaries generated as part of ASP.NET Dynamic Compilation?
I was able to solve this using using assemblyPostProcessorType in the compilation tag of the web.config. Basically calling SignTool.exe with certificate info post compilation.
Related
I want to make a "properties style web form" that shows the application version for various .NET applications.
If I know the URL e.g. /someapp/default.aspx is it possible via reflection to execute that page and figure out the assembly version?
It's quite easy to find the executing assembly version, but without modifying the other application, is it possible?
Both the property page and the other application is running on the same server and in the same application pool.
Update: I've had some luck with
var url = "~/SomeApp/default.aspx";
var appType = System.Web.Compilation.BuildManager.GetCompiledType(url);
But navigating appType to find the assembly file version is not the same everytime.
Without modifying the web application to expose the version number through some URL-based retrieval (a simple page GET being the easy, obvious one), you're going to need to find a way to figure out where the DLL for the web application is from the URL.
If you can know the DLL's location, either by some convention (e.g. /appX/ is always at D:\Sites\appX\bin\appX.dll) or some configuration (you manually enter where each URL base's DLL is in a database), then you can retrieve that DLL's assembly version using the following code:
Assembly assembly = Assembly.LoadFrom("MyAssembly.dll");
Version ver = assembly.GetName().Version;
Code taken from this question.
Edit:
I've had a little look around, and there are some APIs to inspect the IIS configuration, so this is certainly a route to explore if you're trying to get from the URL to the assembly location. This question has an example of getting the physical path from the application/site name, for example. Microsoft.Web.Administration is the assembly to explore.
The ASP.NET engine streams nothing but HTML, javascript, etc.. to the client. There is nothing left of the assembly that gets passed in the response that can show what version of .net/asp.net that the application is running unless the developer on the server side adds it.
That said, you can gather some information from a utility at http://uptime.netcraft.com/up/graph that will give you some server information. Not down to the assembly version, but this is as close as I believe you are going to get.
You may implement custom HttpModule, put it to the bin folder of each application that you wish to monitor and append register this module in web.config files. In this module for example you should handle request, retrieve all required information and put it to response cookie.
i find this question tricky but what files store method signature info for xml webservice?
.dll, .asmx, .wsdl, .disco ?
TIA
It goes into a DLL once compiled, but it's in a code file when added to the project (referred to as a proxy class, it's in whatever language your project is). When you add a web reference it's imported this way. Updating the reference updates the .cs (or vb, whatever you're using).
If you want to see what happens, you can generate the code file yourself, see MSDN for details.
So overall: It is WSDL when fetched, converted to a code file when included (or updated), then finally compiled with the rest of your code into the DLL.
I have several DNN modules that I wish to update silently, using the portal's built-in module upgrade facilities called from a separate application, in this case a Windows service. I was able to make it all work with version 4.3 of the portal by modifying the DNN source in key areas to allow DotNetNuke.dll to function outside of a web application. I'm now trying to do the same thing with the 4.9.0 source code and I'm having problems.
Everything works fine until DNN tries to read from the database. I have my Windows service project, the DNN library project, and several other related projects loaded in one VS solution (the additional projects are the same ones that are in the main solution file provided with the DNN source). I call PaInstaller.Install in my service to update each module. Execution gets to reflection.vb and then it tries to create a DotNetNuke.Data.SqlDataProvider object based on the type name. It raises an exception when calling System.Web.Compilation.BuildManager.GetType. The exception says:
Could not load type 'DotNetNuke.Data.SqlDataProvider' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I read this to mean it simply couldn't locate the DotNetNuke.SqlDataProvider.dll assembly. What's strange is that assembly is in the Bin folder for the DNN library project, and I also have it in the folder where my Windows service is running. The actual SqlDataProvider project is also loaded in the solution. I can't for the life of me understand why the runtime environment can't locate the assembly.
Has anyone tried something like this before, or know what could cause an assembly not to be found while stepping through the DNN source? Am I better off using something other than BuildManager.GetType to get an instance of the SQL provider type?
Chris,
Honestly depending on your needs, I would look at doing this a different way, as this is going to be very fragile with each DNN upgrade that happens in the future.
I'd look more towards using the "bulk install" option that DNN already has. Have your service upload the module zips to the /install/modules folder, then from there, call /install/install.aspx?mode=installresources and you are done!
If you need a third party solution to parse the results, have your windows service go through and pull the HTML response and parse it to validate success.
According to the MSDN documentation (http://msdn.microsoft.com/en-us/library/ms172987.aspx), the My.Application.Log property is used to write log entries for client applications, and the My.Log property is used to write log entries for web applications. However, I have a web application with a bunch of My.Application.Log calls in the .aspx.vb files. These compile correctly, but if I change them to My.Log, I get compile errors. Does anyone know why this would be?
I've got this problem too.
This seems to happen when you write to log from a library (dll)
which is a sort of windows application.
Do you use a Dll?
I've a simple, if not primitive, C++/CLI .NET 2.0 class library. It is used in order to wrap some C++ legacy code for the Web Service. The following facts appear to be true:
Primitive C# test program calls class library and it works.
If class library does not refer to any modules of our code base, it works as well as part of the web service. That is, I load the web service and invoke the methods and receive proper response.
The same moment I replace the copied and pasted code by the calls from our code base libraries, the Web Service stops to load. I get System.IO.FileNotFoundException message.
The problem: I cannot find any place where the file name that couldn't be found is written.
I googled it and gave some permissions to some ASP.NET user on my computer. I copied all the DLLs of our libraries into the same directory where web service is installed. I searched in IIS logs, event logs, etc - no where could I find the name of the module that prevents the web service from coming up.
Any help on the matter would be greatly appreciated.
Boris
Make sure all the dependent DLLs are in the path (Path meaning not the directory where your assembly is, because ASP.net copies your assembly away into a temporary folder, but rather a directory that's included in the System path environment variable).
What calls are you replacing? Could it be the original code gracefully handles missing files (which may not even be important) and yours does not?
Add same rights to the iusr-account that you did to the asp.net-account.