How does Visual Studio process the App_Code folder when a change is made or detected in it? Not IIS or ASP.NET.
I want to gain a better understanding of why Visual Studio freezes for long periods of time whenever I save a code file inside a large App_Code folder of a website project. Alternatively, I could ask: why does Visual Studio not exhibit these same freezes when processing a file inside a class library that is equally large?
Ideally I would like to see official documentation cited from Microsoft of the issue at hand of processing the App_Code folder in Visual Studio and what happens that differs from processing a class library for example.
The App_Code folder is not explicitly marked as containing files
written in any one programming language. Instead, the ASP.NET infers
which compiler to invoke for the App_Code folder based on the files it
contains. If the App_Code folder contains .vb files, ASP.NET uses the
Visual Basic compiler; if it contains .cs files, ASP.NET uses the C#
compiler, and so on.
If the App_Code folder contains only files where the programming
language is ambiguous, such as a .wsdl file, ASP.NET uses the default
compiler for Web applications, as established in the compilation
element of the application Web.config file or the machine-level
Web.config file. Compilers are named build providers and a build
provider is specified for each file extension in an extension
element.
See the documentation here.
It recompiles all code in this folder in a separate assembly, then reference this assembly in your project.
You should be aware that a double reference could occur if you include these files as compilable in your project. In this latter case, the files are at the same time compiles in a separate assembly (with a temp name) which is referenced, and also compiled in the bin folder. This is the start of the horror show ...
These performance notes about the App_Code folder are slightly dated but likely still apply to the project type:
2) Keep the number of files in your /app_code directory small. If you
end up having a lot of class files within this directory, I'd
recommend you instead add a separate class library project to your VS
solution and move these classes within that instead since class
library projects compile faster than compiling classes in the
/app_code directory. This isn't usually an issue if you just have a
small number of files in /app_code, but if you have lots of
directories or dozens of files you will be able to get speed
improvements by moving these files into a separate class library
project and then reference that project from your web-site instead.
One other thing to be aware of is that whenever you switch from source
to design-view within the VS HTML designer, the designer causes the
/app_code directory to be compiled before the designer surface loads.
The reason for this is so that you can host controls defined within
/app_code in the designer. If you don't have an /app_code directory,
or only have a few files defined within it, the page designer will be
able to load much quicker (since it doesn't need to perform a big
compilation first).
-- http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx
Related
I have a customization project where I'm importing an Excel file content into the Lot/Ser No. Allocation grid. This works fine on my machine, but I had to download the DocumentFormat.OpenXml dll and include a reference in my class library project in order to do this. I've created a customization project, but when someone else tries to use it, that reference and that file are not there. I've tried to include it in the files section of the customization manager, but I have no way of doing that (can't browse to a file) - not that that would make any difference anyway, since that's the bin folder of the website, and not the class library.
Bottom line: Is there a way to include a dll file that's used in the class library project references in a customization package?
Add the dll file in Bin folder of your local website -> the file should appear in the Add Files dialog inside Customization Project Manager
Select the dll file in the Add Files dialog and click Save
After that, DocumentFormat.OpenXml.dll becomes a part of your customization package, which will always deploy it together with your extension library
Ruslan provided a good answer explaining how to include your custom DLL, however you might want to know that there are built in functions to read Excel files which make inclusion of third-party libraries unnecessary. Please refer to the following article: http://asiablog.acumatica.com/2016/03/reading-excel-file-acumatica.html?m=1
I'm new to C++/COM. I have created a ATL COM Project with a callback mechanism to send messages to managed side. It has one idl file (sample1.idl) which expose 'n' number of methods, hence managed environment can access it. Now i would like to add another .idl(sample2.idl) file to that project.
.tlb is created for both sample1 & sample2 and build succeeded. On browsing the .dll , I couldn't find the sample2.idl related stuffs. I suspect that .tlb generated from ‘sample2.idl’ is not reflected in the .dll.
Can we have more than one IDL’s in the ATL (COM) project ?
The default for ATL, as with many native build environments, is to embed the type library as a resource in the DLL. Something you can see in Visual Studio (retail edition required), use File + Open + File and select the DLL. Open the "TYPELIB" node, you'll see one type library with resource ID #1. This is the one that Visual Studio sees when you use Add Reference.
Most any build tool that consumes type libraries will only ever look for that one resource. Visual Studio is no exception. It also can encode only one type library in its project files. You perhaps can make it work by selecting the 2nd .tlb file with the Add Reference dialog. Albeit that it is very likely that you'll now get exposed to more problems in your ATL project, like forgetting to register that 2nd type library in your .rgs file.
Very hard to give proper advice without any hint what that second IDL file might contain. Stay out of trouble by merging them or by using the existing support in IDL to import other .idl files or type libraries.
To internationalize&localize my Visual C# 2010 Express project I created Resources.resx and Resources.fr.resx containing key-value strings:
When I press Rebuild, two DLLs get created:
obj/Debug/tempPE/Properties.Resources.Designer.cs.dll
obj/Debug/tempPE/Properties.Resources.fr.Designer.cs.dll
Why in this odd location?
Should I embed those in my installer?
No other Resources DLL are generated anywhere so I have no choice, but it is scary to ship files coming from a "tempPE" folder...
Remove Resource.fr.Designer.cs file. It should not be there. Resource.Designed.cs is enough.
Only the default language file needs an Access Modifier of Internal or Public. All other language files need "No code generation".
The obj folder you can ignore. It is there for the build process and for Visual Studio's purpose. All you need for your program to work is in bin. You can delete both folders, they will be recreated.
Our product includes several DLLs built from open source into files with default names as delivered by the open source developers. We're careful to install the files in our own directories and we carefully manage the search path (only for our processes) to keep the loader happy.
Another developer -- a towering intellect -- decided it would be easier to install their own build of some of the same open source into C:\WINDOWS under the same default DLL filenames. Consequently, when we launch a process which depends on these open source DLLs, the system searches C:\WINDOWS before our directories and finds the DLLs installed by the other developer. And they are, of course, incompatible.
Ideas which have occurred to me so far:
rename all our DLLs to avoid the default names, which would only make
it less likely we would encounter collisions
load all our DLLs by full path so the loader captures their names into
RAM and doesn't search anywhere else the next time they are requested
For various reasons, neither of these options is palatable at the moment.
What else can we do to defend ourselves against the towering intellects of the world?
You've got only two options: deploy the DLL in the same directory as the EXE (that's where Windows looks first) or using manifests and deploy the DLL to the Windows side-by-side cache. I don't think the latter option is common in the Open Source world but it is the only real fix if you want to share DLLs between different apps.
To add to the already excellent answers, you have a couple more choices:
The preferred solution(s) to this problem, supported since Windows XP, is to turn your dll's into a win32 assembly (They don't have to be .NET but the documentation on creating win32 assemblies with strong names is appallingly light so its easy to get confused and think this is a .NET only technology).
An assembly is noting more complicated than a folder (With the name of the assembly) containing the dlls and a .manifest (With the name of the assembly) that contains an assemblyIdentiy element, and a number of file nodes for each dll in the assembly.
Assembly based searching works even when dlls are statically linked!
The easiest option is to create unversioned assemblies and store them in the same folder as your .exe files (Assuming all your exe's are in a single folder).
If the exe's are in different folders, then there are two ways to access shared assemblies:
You can store your assemblies in a private alternate location if you expect your application to be used on Windows 7 and higher. Create a app.exe.config file for each of your exe's, and point a probing privatePath element to a common folder where you are storing the assemblies.
If you are ok with requiring administrative access to perform installs, (via MSI's) then you can deal with the appallingly bad documentation (well, absent documentation) that deals with giving your assemblies a strong name, and then store the assembly in WinSxS.
If you can't, or do not want to bundle your dlls as assemblies then this page covers dll search order
Using functions like SetDllDirectory are only going to help for dlls loaded dynamically at runtime (via LoadLibrary).
Dll search order used to be:
Directory containing the process exe
Current directory
various windows folders
PATH
Which you could have used to your advantage - launch each exe, setting the "current" directory to the folder containing the OSS dlls.
With the advent of SafeDllSearchMode the search order now is:
Directory containing the process exe
various windows folders
Current directory
PATH
Meaning theres now less control than ever :( - It goes even faster to the "untrusted" c:\windows & System32 folders.
Again, if the initial dll is being loaded via LoadLibrary, and its the dependent dll's that are the problem, LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag will cause the following search order (Assuming you pass a full path to LoadLibraryEx) :-
Directory part of the Dll path passed to LoadLibraryEx
various windows folders
Current directory
PATH
The directory from which the application loaded is normally the first directory searched when you load a DLL. You can, however, use SetDllDirectory to get the "alternate search order". In this case, the directory you specify to SetDllDirectory gets searched first.
There is also a SafeDllSearchMode that affects this to a degree. Turning it on excludes the current directory from the search.
Maybe just compile them to a static library?
Why not?
Also, the current directory, where the exe is activated from is searched before c:\windows.
I am working on a sharepoint feature which includes a couple of list definitions, 2 webparts, a feature receiver assembly and an InfoPath form.
I have to use WSPBuilder to package these, and the requirement is to package all these features into a single WSP solution file.
Now, WSP builder requires the deployment files in a particular folder structure, same as the 12 Hive of sharepoint.
My problem is that all my features were developed separately, and consist of multiple project files, and these are not necessarily in the same folder structure..
How do I use WSP Builder to package multiple features into a single WSP solution?
Maybe this will help: http://www.codeplex.com/wspbuilder/Thread/View.aspx?ThreadId=43125
Ultimately, I think you gain a lot of flexibility by building your own wsp files by using a tool like NANT.
There's no particular action you need to undertake in wspbuilder to have multiple features in the same solution package.
All you need to do is create a new folder for each feature under the 12\TEMPLATE\FEATURES folder inside your solution in Visual Studio and place the appropriate feature.xml file in that folder. For example, you may have:
12\TEMPLATE\FEATURES\FancyFeature\feature.xml
12\TEMPLATE\FEATURES\ReallyCoolFeature\feature.xml
... and so on.
Upon building the solution, wspbuilder will read the entire tree structure of your 12 folder and append the corresponding nodes in the wsp's manifest.xml file. The same goes for any other possible subfolders inside the "TEMPLATE" folder, including IMAGES, LAYOUTS, etc: at deployment time they will all be copied in the correct folder inside the real 12 hive, because the 12 folder inside your solution is meant to be a replica of the original one.
For a better understanding, create some folders and files inside your 12 folder in the visual studio solution, compile your project and look inside the generated manifest.xml file.
The simple answer is that you are going to have to copy all the files form the individual projects into one master project for your solution. As long as all your individual feature files are in the correct location in your '12' folder then you'll be good to go.
Note: You'll need to check all your references to any assemblies as this solution will create 1 assembly for all your custom logic.
I had trouble adding dlls to the wsp so I wrote a short article about it: How to Add DLLs to a WSP Solution
I usually have one project in the solution designated as the "main" one. I set the dependencies so that this "main" project is built last. Then for the other projects that I want to be included in the wsp package, I edit the "Post Build Events" to xcopy the contents of the 12 folder and that dlls built by the projects into corresponding folders for the main project. Then after I build the whole solution, I can build the wsp package for the main project and know that it contains everything.