Questions:
Are XAP files self-contained?
Do they link in all DLLs I have referenced in the project?
If I need to distribute my app, is all I have to do is hand someone the XAP file?
By default, yes. For alternatives, see answer 3.
By default, all except the core DLLs installed by the runtime; it will contain anything from the SDK, Toolkit, 3rd party controls, or your own libraries.
By default, yes. However, there is an option as of Silverlight 3 to package certain assemblies (for example anything from the SDK) into separate ZIP files, which are downloaded separately. In Visual Studio, look in the project properties for a checkbox called "Reduce XAP size by using application library caching." This option toggles whether to create/use the ZIP files or not. Enabling the ZIP option allows multiple Silverlight apps to share the dependency on the ZIP files, so that instead of packaging everything into the XAP every time, you just download the ZIP for one app, and it's saved in the browser cache for other apps.
As for the general contents of the XAP file, there are 2 important bits:
Foo.dll - your project's main assembly (renamed as appropriate)
AppManifest.xaml - describes the requirements for you app, e.g minimum runtime version required, the entry point into Foo.dll, and other settings, including Out-of-browser settings, or whether to use the Library caching feature mentioned above.
Anything else is just content used by your app.
Silverlight XAP files can be tricky if you're using anything other the the core silverlight assemblies (eg. SilverlightToolkit).
XAP files are just zip files - open one up and take a look. They are self contained to the extent that any custom/extra dlls are included - the standard Silverlight assemblies will be installed when a user installs Silverlight.
References to dlls are required in the .proj files for every assembly that will be used. Ie. unlike other project types, if one project references another project, both projects need to reference all dlls used by either project.
You should be able to just hand someone the XAP file if you want - but Silverlight was designed to be used in browsers, so you will need to include the generated test page at least. The best, and most useful, is to provide a publicly accessible web page that hosts your silverlight app.
HTH.
Even though this question is already answered, i'm going to throw this one in too because it hasn't been mentioned yet.
You mention that you are using SL4 - if you are running out of browser (OOB) then you can just ship the XAP file, and use sllauncher.exe (2) to "install" it to the client machine. As part of that install you can also specify where updates are to be sourced from, which is important for when you find bugs or the requirements change.
Related
I have install some asp.net core mvc dlls (Microsoft.AspNetCore.Mvc.Abstraction.dll). I want to decompile it and see the source code.
The dll is added to my project>Dependencies>Nuget.
However, I am not sure where exactly the dll in in my system.
Is there a quick way to just launch the added dll in ILSypy and see the codes or at least the object inheritance tree?
Thanks.
ASP.NET Core is open source, so as Hans wrote as a comment to your question, you can look directly at the source, you don't need to decompile.
But for future reference, NuGet dlls are extracted to one of two places. Older projects still using packages.config, the dlls are typically extracted to a folder named packages as a sub-folder of where the .sln file is.
Packages using PackageReference, the packages are extracted to your account's global packages folder, which by default is %userprofile%\.nuget\packages on Windows and ~/.nuget/packages on Linux and Mac. You can also look at your project's obj\project.assets.json file to find the paths to everything referenced.
All paths can be modified with nuget.config settings (or even msbuild properties for projects using PackageReference). But if this is the case, either you, or your team mate would probably know, so the default locations for the folders I listed above should be correct.
I have a Web Site and Class Library built with ASP.NET 5. The Class Library depends on an set of external files (XML, EXEs, etc.). Those dependencies are added as part of the project and visible in the Solution Explorer of Visual Studio.
My Web Site has a dependency on the Class Library. When I build the Web Site, I would expect the dependencies of the Class Library to be copied to the Web Site, but they aren't.
The Build Action (Copy always, Copy if changed) appears to be gone with ASP.NET 5. How do I make sure that dependencies other then the DLL of the Class Library itself gets copied to the Web Site project?
First thing first, they won't be in src/yourProject/bin/Debug. Those have been moved to the artifacts folder.
Also, your project by default will not output DLLs. This is mainly due to performance reason but if you need your DLL to publish your application, check your project properties. In the Build section you should have an option called Produce outputs on build. Tick that and bingo.
You have your dlls. Most of the time (aka: while coding), you won't need them since they will always be recompiled in memory.
You need to manually add a pre/post build step in project.json
I am nearing deployment time and am at a loss at to which files to package and deploy when the day comes.
Can I just pull out the executable and be done with it? Or do I need the XML docs and vshost files/manifest files?
Also, the DLLs I am using are also accompanied by an XML document inside my /Release/ folder. Do I need those or can I just grab the DLL files?
Thanks.
At minimum, you need EXE + DLLs. If applicable, add a default config file as part of deployment.
You may want to include PDBs to help debugging.
You don't need XMLs.
For the development machine, if you're using all default controls from Visual Studio, you only need the .exe. Just install the targeted framework. If your app is running in .NET framework 4, then you only need to install framework 4 and your .exe alone will run fine. If you're using 3rd party controls, then you need the .DLL in the same folder you have your .exe, usually.
I've read that placing an empty file named <AppName>.exe.local in the application directory will cause the application to look in that directory first for DLLs and OCXs so as to avoid issues with conflicting DLLs and OCXs found elsewhere on the system.
But doesn't the application first look in the application directory anyway? What effect does the .local file actually have?
To be frank, I've never heard of the .local scheme before, but a quick search brought up this article which quite explains it:
For an application foo.exe, if there is a file foo.exe.local exists, Windows will first look at foo.exe’s application directory, before start the regular dll search. To mitigate the COM problem, the redirection applies both to full path dll loading, as well as partial name loading.
It appears that the .local file forces even absolute-path searches to the application directory first, whereas usually absolute paths are unchanged and only relative paths follow the DLL search order.
Applications can depend on a specific
version of a shared DLL and start to
fail if another application is
installed with a newer or older
version of the same DLL. There are two
ways to ensure that your application
uses the correct DLL: DLL redirection
and side-by-side components.
Developers and administrators should
use DLL redirection for existing
applications, because it does not
require any changes to the
application. If you are creating a new
application or updating an application
and want to isolate your application
from potential problems, create a
side-by-side component.
Ref.: Dynamic-Link Library Redirection
We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.