Dynamic ASP.NET application compilation - c#

My web application (ASP.NET v3.5 / C#) dynamically creates other asp.net applications (creates aspx, aspx.cs, classes, web.config, project.csproj file etc.).
The thing is even after I configure the 'new' application folder as APPLICATION in the IIS, When I try to browse it, I get the following parser error: Could not load type 'Template48.Template48' (where Template48 is my application).
When I manually browse to the new application folder, and re-build it, all works perfect.
How can I re-compile this WHOLE application, but in it's folder ?
Thanks in advance,
Gal.

A web application needs to be compiled before it works; this is different from a web site.
Just providing the sources isn't enough; in fact, ASP.NET doesn't need the sources (aspx.cs) to run the application, just the .aspx, web.config, and .dll files ("assemblies" in .NET lingo). It is even considered good practice to remove the sources from the production system to avoid accidentally leaking the sources and giving attackers information about the site's inner workings.
To make this work, you need to somehow invoke the command-line C# compiler to build the project on the fly; this will generate the needed .dll files.
A different, but much harder, route would be to use .NETs ability to emit IL at runtime; using this facility, you could produce assemblies directly without going through the compiler. This is pretty difficult though, and you need thorough understanding of the IL to pull this off.

Related

Imported website into web application in visual studio gives 'Type typename already defines a member'

After importing this existing (and functional) site into Visual studio (tried 2017 and 2019 both) running .Net 4.0 I am getting a plethora of not found errors.
Codebehind pages are not able to see elements on the existing page
Classes are declared to be duplicated or ambiguous
Function names (both standard like Page_Load and custom) are reported as already defined.
I am sure that all these items are related. Here are the steps I followed:
Created new Web Application from Visual Studio 2017 template
Copied solution and csproject files into existing website folder
Added files into the project
Re-added references to site
Set custom class .CS files to Compile
Removed "unnecessary" using statements (which were already declared in web.config)
Create a new ProfileCommon stub referencing ProfileBase
Beyond all this I have tried renaming a number of these functions and classes (using the rename) to create a new reference point.
Not sure what else I can do on this beyond major changes or a complete rewrite (100+ pages of code so far) by creating the new class files then copy/paste.
What other options are open to me?
Ok, this is is a migration project. Only you can "determine" if you want to convert from a web site to a web site application, and the time and efforts for such a migration project.
Now, having stated the above? No question, that I prefer hands down a web site applications. Simple things like have VS compile and build the application, ability to add assemblies (and not have the mess of .dll's HAVING to be in the bin folder to resolve references - yuk!).
And then simple things like the ability to multiple projects in one project are things I come to enjoy, and expect over the years when developing software.
About the "only" thing going for a web site? Your deployment is oh so easy, since you can open a web page, or code behind, hit save, and you are done!
but, this means both source code (code behind) has to be deployed to the web site. As noted, I prefer a build and compile process in VS. This does mean that to make a "minor" change, then you have to do a full re-deploy of the whole site.
However, these benefits I like and enjoy? it not all a given that converting an existing web site to a web site application is worth the efforts. Only you can make this decision. On the other hand, you would not be doing this work unless you KNOW what you doing, and thus can determine if these efforts are worth the time.
Such a conversion and refactoring process is somewhat beyond a simple post on SO.
However some steps and tips are outlined here:
https://devblogs.microsoft.com/dotnet/converting-a-web-site-project-to-a-web-application-project/
I would consider starting over, and try the steps in above.
There is a "convert" option outlined in above, and this can save enormous amounts of time. It has been some time since I have attempted such a conversion, and I not tested the "convert" option in vs2022, and hopefully it still exists.
However, another possible option? Keep the site as web site.

Using external DLL's in C# COM-DLL project for MS-Access usage

The user's main application is ms-access (with ms-sql server). Ton of code in vba.
One of the main features i have to manifest is controlling my client's voip telephony. My plan is to make a COM DLL that the ms-access can use.
As of now, i've managed to write a C# project (vs2019 .net framework) that handles the voip pbx well, using json, and do all missions necessary, such as invoking calls, sending sms, get calls list, recodings list, get recordings wav files and convert them to mp3. I use Newtopsoft.Json and NAudio.Lame.
BUT it only works as a standalone .net project or exe.
As a COM DLL (class library) - ms-access can handle and use it UNTIL it gets to the part where the code uses ANY external dll's functionality - and it crashes (with newtonsoft) or just not working (with naudio), although the dll's are in the working folder.
I know i have to found a way to make these external dll's to work under the office (32bit) enviroment.
I was trying and guessing many code samples for a couple of days. I tried to follow the Assembly.Load/From/File examples to dynamically load and include the dll's, but i failed to assimilate it in my code or even to understand it enough.
I hope i'll get a solution here.
Thanks :)
Hum, I am able to create a COM object for use with Access. External library code (in my case Newton soft) for serializing data works just fine when that class code is used as a COM object from Access.
You don't mention if the other libraries are managed code, or external win32 .dll? I have however used un-managed .dll’s with a .net COM object, and then have consumed that from MS-access.
The only issue would be in project explorer is to ensure that you have a copy local setting = true for the external referenced .net .dll libraries. (And that is the default, so I am sure you do.
The next issue of course is of course is there any use of configuration files? (app.config) etc.? The reason for this of course that since your application is being launched with msaccess.exe, then the config and settings will be assumed to be in the office install folder, and not the local application. As a result, it not all so practical to move/copy those app.config files to the office folder where msaccess.exe resides. And the config file name will not only have to be in the same folder, but also named.
Msaccess.exe.config.
In place of
YourDotNet.exe.config
Now of course, if you build your project as a .net exec? Well then of course any config settings (application ones, not user) will be placed in this config file, and of course that file will have to be placed in the same folder as the .exe file.
So, one might add a “test” function (any function is a method of that class) to the class that you test/call from VBA to ensure that such settings are being seen and read (if you are using any settings).
Eg:
System.Reflection.Assembly.GetExecutingAssembly().Location + ".config"
So, return that to access and display this result.
The other issue is of course to FORCE your project to x86. I would not use “any” CPU. While this “may” work, since you are using access x32, then I would force compile your .net class to x86 as opposed to “any” CPU. This would also spit out some errors in case some of the external assemble(ies) are compared to a particular bit size and thus x86 settings will result in your class not consuming some of the external .net .dll’s.
Now you “note” that your project works as an .exe, and then “sort of” works as a class and “.dll” registered as a COM.
However, you don’t mention how you are “flipping” this from an .exe to a class, or do you simply have a .net “test” project that you run as an .exe, and it of course has a reference to that class .dll. And you NOT using “COM” for this testing.
If your test.exe program can use that external assembly?
Then I would create a test2 project, but this time around do NOT reference the assembly (as .net), but try using .net CreateObject(). (I think c# has this choice – vb.net certainly does).
So you could try + use a CreateObject() in this .net test sample, and thus test from .net as COM.
So this test .net program (one that has NOT referenced the assembly) would a intermediate test before you jump all the way into ms-access + VBA test code.
However, I would first test/check if an app.config file is being used here, since as noted when you flip to a COM object, and then create a instance of that object in Access/VBA?
Then the config file will NOT be used. You can in .net code force/change the app.config file in that running assembly, and I can’t seem to find my code example that does this. But I am not going to dig too hard until such time we confirm that you are using app.exe.config file here.
Edit
Out of cuirous, I googled naudio. It is managed code. So, that library should work just fine. If that project is compiled as "ANY CPU", you COULD try re-compile as x86, and also re-compile your test program as x86. Then when you create a COM object, then again compile that as x86.
As noted, I do quite a bit of COM stuff for ms-access, and I have without issue used Newtonsoft (for jason serializing/de-serializing) as a COM object that is consumed by ms-access.
And given that naudio is managed code then I don't see why it would be an issue. Any other 3rd party .dll's you using here? As a quick test, I would set all projects to x86. You seem to "mention" that "some" of the COM object works, but just not all.

How can I run a code once per application domain in .NET Core

We have a library that is used by multiple companies. They have read-access to built DLL files which are obfusticated.
For each project this library is used, they should pay us. We want to have a telemetry system to make sure that they don't run this library in a non-agreed project.
We thought about somehow calling a telemetry URL each time a process on Windows is started that loads our DLL files. But we need to do it without requiring any coding or configuration from their side.
Is that possible? Can we implement a mechanism in .NET Core inside our library that whenever loaded inside the AppDomain is called once per process lifecycle?
Of course I know we can write code at Program.cs, but in our case, we don't have access to Program.cs and we can't ask them to code, or config anything.

Is it necessary to deploy the XML file in a class library?

I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.

Web Deployment with Project Dependencies failing

probably this is an easy one.
I have a solution that contains two projects:
a web page (asp.net)
a project that contains logic (Project B)
I am set up the web in a server and it loads ok, but when it needs to use the Project B I get an exception showing that it is searching a class in the path of the machine where the code was compiled. This image is the exception I am getting (in orange the path of the compilation machine):
How can I configure the web in order to tell where to search the files of Project B?
Really appreciate any help
I get an exception showing that it is searching a class in the path
of the machine where the code was compiled.
Wrong! C# compiles to intermediate language (IL) and this last one is the executable code which is also compiled to machine code using the JIT compiler or NGen-ing the IL..
You find that class file path because you're publishing your Web app using the Debug configuration and you're also including the .pdb files.
While I find that part of your question is a possible duplicate (see my close vote comment in the question itself), I wanted to add an answer to demystify your statement:
How can I configure the web in order to tell where to search the files
of Project B?
In .NET, executable code is compiled into assemblies, either executable or dynamically-linked libraries (DLL). That is, these class paths to your actual code location in your machine are just debugging information to make your life easier when looking and finding issues during some execution call stack.
The files names are from whatever machine the .pdb file for your assembly was generated on.
From MSDN:
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program
Your problem looks like a database connection issue (which is explicitly said in the exception). Please check your connection string and make sure that your database is accessible.

Categories