I create *.xll with XLW lib. But it work only on build computer. If i rebuild my project on other computer xll work on it, but not my computer. Anybody have idea from this problem.
This sounds like a classic case of you needing to deploy the runtime libraries of your tools to the machines which run the software. Your dev machines will have the necessary runtimes already. Exactly how to do that depends on which compiler you are using. The quick and dirty approach would be to link statically to the runtime.
If you use http://xll.codeplex.com the default is to link with static libraries. Should work on any machine.
Related
I'm building a dll(c# assembly which implements some interfaces) that's called by another app. the dll built on my machine works but the one built on our build machine does not work. I have very little control on that app and can not debug it, I can only see the output of it. Is there any way to check the differences of the dlls? I have used reflector, but it only shows limited info like classes and methods.
I also tried building it on other machines with vs2005, xps can create correctly, server 2008 and win7 can not.
could you guys help me with it? any help would be appreciated. If I was not clear, please let me know.
Thank you!
Since you didn-t tell us the error-symptoms of "does not work" here is my guess formulated as a question:
Does your dll reference other dlls that are installed in global-assembly-cache? do all build machines have the same version of the gac-dll installed?
So I have a C# application and part of it references the microsoft office interop assemblies. I'd like to gracefully handle the case that the user doesn't have office installed, but to do so, I need to be able to test the case that office is not installed. Short of uninstalling office, or actually uninstalling these assemblies on my machine, is there an easy way to test this? I found the assemblies in C:\Windows\assembly, but it doesn't look like there's an easy way to rename them or move them temporarily (at least not in Windows 7). i.e. Can I fake out my application to believe that these assemblies aren't installed so I can test this code path? Thanks for any help you can provide.
Short of uninstalling office, or actually uninstalling these assemblies on my machine, is there an
easy way to test this?
Test it on one of your testing vm's ;)
Here is the situation : Our Dev Team has heterogeneous OS systems, scattered between 32-bit and 64-bit. This is not ideal, we are actually planning to homogenize our infrastructure, but in the meantime we have to deal with it.
The issue is that when a 32-bit developer checks out a 64-bit solution on SVN, he has to manually change the target platforms all over again to get it compiled (not to mention other side problems)
My question is : What clean (though temporary) solution could be addressed in such situation, permitting each developer to keep his default project/platform settings while checking out and in from SVN.
I guess that -at least for the first time a project/solution is checked out, a dev still has to tweak the setting manually to compile it properly. After that, according to relevant SVN filters, it is possible to ignore some settings files (which ones, by the way?)
I am open to all clever and detailed suggestions.
Thanks.
Are you checking in .suo and .user files into source control? As these should be developer specific and should not be included. Pretty sure the suo maintains the build state of the project for each user.
Another option, is execute builds from scripts. For example I have 4 different build script files wired up with autohotkey to build in the background release and debug mode version of a project. This can be configured via msbuild or nant on how you want the project's configuration to look.
This has a benefit of not tying up visual studio.
It has a downside of further work customizing your solution, but long term I think you're in a better situation.
Is there a reason you're specifically targeting solutions at 32bit and 64bit?
eg: Native, unmanaged DLLs?
If you use the "Any CPU" platform option, then .NET will natively run it in either 64bit or 32bit mode depending on what's available on the machine.
Edit:
The other option if you must set the CPU Mode statically is to set up an x86-32 and x86-64 build configuration, and then have your developers select the appropriate build configuration on their end.
I would strongly suggest figuring out what's wrong with your AnyCPU mode though, as if you don't - you need two install packages for your users based on their OS mode.
As long as you are using only managed dotnet-code (no native 32/64bit code) every body can work with 32Bit solution only on 64bit and on 32bit dev-stations. On win7-64 visual studio also is a 32 bit app.
Is it possible to deploy a .NET 2.0 application as a portable executable?
So that my program can be ran in a Flash Disk without the .NET Framework 2.0 installed in the target machine. Or maybe is it possible to distribute my program with the required .NET DLLs, so that no framework installation is necessary?
I know that there are some alternative tools to turn my .NET exe into a single native executable like RemoteSoft Salamander, Xenocode Postbuild, and Thinstall, but unfortunately I can't afford one.
I also tried to embed the dependencies with Mono's mkbundle, but it messed my program up =\ (no XP visual style, broke some controls and its functionality)
Any kind of help would be appreciated :)
Thanks.
fyi: my IDE is Microsoft Visual C# 2008 Express Edition with .NET Framework 2.0 as the target framework.
Well, other than things like Salamander and Thinstall (now VMWare ThinApp) you would have to have .NET installed if you really want to run .NET.
It may be possible to run Mono without actually installing it (not statically linking your program, but including Mono on the flash drive). I suspect it would be tricky though, as you'd have to tell the runtime about things like the GAC location.
I can't see anything in the Mono FAQ about this, but you might want to ping a Mono mailing list - it sounds like a potentially interesting and useful thing to be able to do.
No; you need either the framework installed, or the tools like you have mentioned.
You could potentially look at mono's new static linker, but that is about it...
I have not tried this myself but here's the procedure:
Make a C# project.
In Solution Explorer, inside your project, there is a line "Reference". Click the plus near it. Now you can see all the dependencies of your project. Delete all references that aren't used (delete, and try to run/build. If it is possible to do it, that it is unused. If there is an error, return it by adding it (right mouse click, "Add Reference")).
For each reference, go to Properties, and in the property "Copy Local" choose "True". For each Image, Icon... make like to the referenced.
Rebuild you project. Now in your Build/Release folder (inside bin) you will see many dll files. Those files have the information of every resource.
Copy all the files in the folder (from step number 4) into a new folder.
Go to the folder: "\Microsoft.Net\Framework\" and copy the file "mscrolib.dll" to the new folder from step 5. If you don't find this file, you can always make a search in the Hard Drive which contains Windows folder.
Now your app is portable (with the whole folder content).
-- Source: http://www.codeproject.com/Tips/392308/Csharp-Portable-Exe-File
Well Thinstall is very expensive and it doesn't work in all situations. If you want to run your app without .Net installed you might run into trouble although there are tools that do that Xenocode has a tool that can do this for you and it's cheaper than thinstall.
But if you ask my opinion it's a bad idea to use them. Better convince your target market to install .Net 2 (Which is pretty much universal these days), and then pack all of your library files into one file using a cheaper Obfuscator like tool (There's a good one from Smartassembly.)
I've used Thinstall for a long time, and I've worked on this technology a lot, so I am not shooting off without experience.
How do I start using Mono in Linux as a beginner when I want to switch from Visual Studio?
Is there some easy way to install it like Visual Studio and get started?
So far,with what I've seen,it looks complex to even get started.
Installing and configuring Mono in linux is a lot of work right?
or Is there some distro which I can directly install and get started with applications in Linux?
I recently started to dabble in Mono myself and have so far realized that the MonoProject has made huge advancements in this area. It's well worth it to investigate.
With that said, the easiest method is to get setup with a Linux distro that is Mono friendly such as Suse, or Ubuntu. Personally, I tried it using Ubuntu 8.10.
Once you've got your Linux distro setup properly download and install MonoDevelop. This is an open source IDE that's tightly integrated to work with the Mono platform. MonoDevelop was taken as a branch of SharpDevelop and designed to work with the Mono compiler from the ground up.
This is by far the easiest and fastest way to get setup with Mono. The MonoDevelop IDE is very similar to that of Visual C# Express even. It comes complete with Project/Solution management, GUI development using the GTK# framework, an integrated debugger and a host of other features you would expect in an IDE such as code-completion, line numbers, code-folding etc.
The folks at the MonoProject are on to something with this suite of tools.
Hope this helps you get started.
Mono Project Homepage
Mono Develop Homepage
There are a few interesting books on Mono, although they're probably a little bit old. Still, probably it's worth to grab one and take a look in order to start up.
Practical Mono
Mono: A developer's notebook
Cross-Platform .NET development
Mono Kick-start
Then, I'd install latest Mono (2.4) on a Linux box (OpenSuse is the one they use, so it will always go smoothly for development, but we also use Ubuntu internally) and start playing around with the compiler, MonoDevelop (which is quite good since 2.0) and so on.
The only tough point will be writing GUI applications, although my team make extensively use of MWF on different Unix flavors. But everything else will go as you'd expect. I'm specially happy with how great remoting works, for instance.
If you're used to Linux then it will be much easier, otherwise I'd also recommend you getting used to it following some tutorial.
Remember tools such us NUnit and NAnt will be also available, so you can start writing your code on both Windows and Linux and testing and compiling on both platforms.
With the just released Ubuntu 9.04 a very current Mono development environment is as close as:
apt-get install monodevelop
I used to agree with you that it was somewhat difficult to get going with Mono, but the latest version of Ubuntu has melted that barrier away. And the latest version of Monodevelop is an absolute joy to use.
Don't use Ubuntu? Then I would go with Peter's advice of using a VMWare image.
For a very easy start with mono under linux u can download
a vmware image
a linux live distro
with everything included to start.
If you are accustomed to using visual-studio, you can still develop in Visual Studio, and copy your binaries to Linux/OSX or whatever. Or even better, if you have a shared drive, just reconfigure your VS-Project output directory to the shared location.
There might be advantages to using the mono compiler, or monodevelop, but since you are getting started, the above is really the easiest thing to do. If you want to run on Linux, the mono installer is an excellent option for getting up and running in a hurry. Unfortunately, there's no installer available for the newest mono release, so you'll either need admin permission, or need to compile from source.
http://ftp.novell.com/pub/mono/archive/1.9.1/linux-installer/2/mono-1.9.1_2-installer.bin
For installing newest Mono 3.2.5+ with MonoDevelop 4.2.1+ it is better is use tpokorra repository.
The simplest way I could find is to download the OpenSUSE VMWare Image on their site and just run it. You get all the tools you need :) Preconfigured.
Debian and Ubuntu, and probably all other children, have mono in the repository. So, setting up mono in Linux can be as easy as
aptitude install monodevelop
However I would suggest version 2 which requires using the 'sid' repository in Debian (don't know about Ubuntu).
vim /etc/apt/sources.list [ :%s/squeeze/sid/g ]