I would like to use some of the classes that are available in Coded UI Tests, such as BrowserWindow, Playback, etc.
But I would like to be able to run the resulting code without using VS, MSTest, TCM, etc, since the code needs to run in tightly scrutinized production environments.
The first thing I ran into is the error:
"FileNotFoundException was unHandled" Could not load file or assembly 'Microsoft.VisualStudio.TestTools.UITest.Playback, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
What do I need to do to get around this? More generally, can I use these classes that are available in Coded UI Tests and run the resulting code without using VS, MSTest, TCM, etc?
You would need to install Visual Studio (or just the the Test tools) on the environment.
Related
I was making a Delphi application, and wanted to test it on another PC to see if everything was working properly. I compiled and built the executable file, of course and I transfered all of the files from the Project folder to the other PC. When I launched the .exe file on the PC, nothing would happen. I then ticked the "Build with runtime packages" option in Project Options:
This made the .exe go from around 300 KBs to around 30 KBs, but now, instead of being able to launch the application on another (non-Delphi) PC, that PC got an error saying it was missing various files required to open the .exe .
I sent the same thing to various friends and all reported the same problem.
My application is a rather simple lottery prototype application, so I don't understand why I'm having trouble opening it on other PCs. Are there other special options I need to enable for this to work?
When you use runtime packages, you need to distribute those packages. These are the .bpl files that your program links to. It will be a subset of the packages listed in the runtime packages edit box in your screenshot. You should just list the packages that you use.
The net result of doing this is that the total amount that you will have to distribute is much greater than a single monolithic executable. Because in a monolithic executable the unused code can be stripped. If you want to minimize the size of your program, and make life simple, do not use runtime packages.
It would be worthwhile reading Embarcadero's documentation:
Working with Packages and Components
Solve the first problem.
Using Runtime Packages will not solve the problem of your EXE not running on certain PC's. All it does is increase the complexity of deploying your application (as you have found).
Unless you need Runtime Packages for other, specific reasons, then you are far, far better off NOT using them, especially if you do not understand them (which based on the way you describe having discovered them does appear to be the case, if we're being honest).
Concentrate on finding out why your application does not run as a single, stand-alone EXE.
With all of the problems involving runtime packages your EXE is currently not even reaching the point of running your application code, and this may be where your original problem lies. Which means that once you have solved all the issues created by Runtime Packages, you will stil be left with an EXE which does not run. i.e. your original problem.
What does your application do when it starts ? Does it attempt to load files from any specific locations ? What are those locations ? What are the files ? Are you using any third party libraries which may expect DLL's to be present or other external files ? Are you trying to read or write settings to the registry or any external files (INI files etc).
What is the OS you are trying to run on ? This can be a very significant question for applications compiled with older Delphi versions. Have you tried configuring the EXE to run in Compatibility Mode for older versions of Windows ? (something that you do in Windows itself, not when compiling the EXE).
These are the questions you should be focussing on. Not runtime packages.
Gday,
A small tool that's been around for a while to help you with this is Dependency Walker. You can find it at http://www.dependencywalker.com. It's helped me out on more than one occasion. This will tell you what files (usually BPLs as stated in the other responses) need to be sent with your EXE.
Also look at NSIS to create a simple installer, and put your EXE and supporting BPLs and any other files in the same directory.
I've just written the first version of a workflow activity that will run Resharper's Code Issues on the projects and parse the output to display the issues as build warnings and errors.
At first, I was going to just call Resharper's command line and parse the resulting xml manually. After fiddling with the dlls in Resharper's SDK (through disassembly mostly), I found a way to parse the results using it's own public classes, which I figured was a much more elegant and safe way to do this.
The first problem I have is that that nuget package is absolutely huge. There is 140mb of files in there, which to me is absurd for a single, unpartitioned package. There seems to be such heavy coupling between them that by using just a few model classes and the parser class, I have to drag a dozen or so of those dlls along, some of them which seemingly have nothing to do with the main dlls I need. This is not a show stopper though, I'm struggling with something else now:
In the end, I managed to track down the dependencies I needed to 41 assemblies (which is, again, insane, but alas). Initially, I tried removing everything and adding the missing references one by one, but this turned out to be unreliable, still missing some indirect references, even after compiling successfully. Then, I decided to code a small console application to find all referenced assemblies in the main Resharper assemblies I used, which gave me the 41 references I mentioned. This is the code I used to find every dependency.
Since these are custom activities we are talking about, I decided to create a unit test project to validate them. Using these 41 references only, everything works correctly.
When I added the activity to the build workflow though, and pointed the build controller to the source control folder containing the required assemblies, every time I schedule a build, the process fails stating that I need one extra dll from Resharper's SDK. For example, this is the first one it asks:
Could not load file or assembly 'AsyncBridge.Net35, PublicKeyToken=b3b1c0202c0d6a87' or one of its dependencies. The system cannot find the file specified. (type FileNotFoundException)
When I add this specific assembly to the TFS folder, I get another similar error for another dll, and this keeps going on and on.
What I wanted to know is how can I know exactly which assemblies a workflow XAML will need in order to run correctly? My custom activity dll has two specific CodeActivities and a XAML only activity that uses these two. This XAML acticity is what I'm directly using in the modified workflow template.
I see that besides the references in my project, the XAML activity also contains a TextExpression.ReferencesForImplementation section, with some assembly names. I've run my dependency finder program on those dependencies too, and the results are the same 41 assemblies already at the TFS folder.
Meanwhile I'll go with having the whole SDK into the custom assemblies folder, but I would really like to avoid this in the future since it has such an enormous amount of unneeded and big dlls in there.
First, we have request for our command line tool to support workflow activity and we decided to implement just plain MsBuild task which is universal and works in TFS too. Task and targets files are included in ReSharper CLT 8.2.
Second, if you still want to implement workflow activity it's pretty easy to do with new API in CLT, designed specially for custom processing of found issues - http://confluence.jetbrains.com/display/NETCOM/Custom+InspectCode+Issue+Logger.
And last, but not least, you do not need to put in VCS binaries of ReSharper SDK package.
Use NuGet's restore package functionality.
If you have any other questions I'll be glad to answer them.
A custom activity is being load and run by .NET CLR like any other .NET program. If the stack trace reports a missing file, then it's required by the CLR and you can't change this fact without refactoring your code.
Having an entire SDK references in the custom assembly folder doesn't make sense. I would prefer GAC deployment over huge binaries folder in the source control. Or maybe consider having these activities running an pre\post build scripts in MSBuild or PowerShell.
Yes, I've read the warning label, and I know that dynamically loading assemblies is somewhat discouraged. That said, I have an application that loads assemblies - that's just how it works. It works fine on Windows. Works fine on Windows CE. I need it to "work fine" on Android, even if it takes some massaging.
Basically the app is an engine that loads up plug-in DLLs (we'll call it an Adapter) that meet specific interfaces at run time. Under Windows, it even detects the appearance of a DLL at any point and goes and loads it - I'm fine if that's not going to work under Android.
What I'm having trouble getting working is having the Engine load an Adapter that it knew about at design/compile time but without hard coding the name of that Adapter into the Engine code. I'm fine with adding a reference to the Adapter to get it to not get linked out, but I really, really don't want to have to add in the DLL name every time, as the DLLs change with different deployments, and that would lead to a huge headache.
So I figured that if it's referenced, it would get into the APK, and I could use reflection to load it like this:
var asm = Assembly.Load("TheAdapterName.dll");
Initial tests show that this works for the Adapter if I just hard code in the name, but again, I really, really want to avoid that.
So I thought that maybe I could reflect through the references and extract the name, but oddly, not all references actually show up when I do that. So I do this:
var refs = asm.GetReferencedAssemblies().Select(a => a.Name).ToArray();
And I get back an array of 14 assembly names. But the assembly (asm) has 16 references, one of which is the Adapter plug-in I need to load. The Adapter is definitely there - heck I used Assembly.Load with the full name two lines above and it resolved.
I thought, ok, maybe I can figure out the "path" to the folder from which I'm running, and then look for DLLs there and load that way. Ha. After several hours of trying to figure out a way to get the path that would work under Debug and Release, I came up with nothing but more grey hair.
Sooooo...... any thoughts on how I might get the name of a DLL that I know is in my APK, but that I don't "know" the name of at build time (I'm loading them and looking for interfaces via reflection to detect their "Adapterness").
If those methods aren't working for you, then the only suggestion I can think of is to add a prebuild step which updates either a C# or an Assets file in order to provide the list you need.
Obviously this is extra work, but should be fully automated and is guaranteed to work no matter what platform changes get thrown at you.
As an aside, I also just looked at one of my mvx projects using reflector - it shows the same asm.GetReferencedAssemblies() list as your investigations report - runtime-loaded plugins are not listed. I guess that the GetReferencedAssemblies method is reporting only on assemblies actually used to import Type references at the IL level - so if you reference an assembly in the csproj but don't import any types then it doesn't list them as references in the compiled code.
Hey all,
I'm just starting with Grails in Netbeans (6.9.1). I got a demo working, but each time i change a groovy file i need to build the project, and then select run (ie the equivalent of "grails build" and "grails run-app"). If there is already an instance running, I need to first shut that instance down.
This seems wrong. It seems like i should be able to just change the groovy file, and it would get automagically reloaded. Isn't that the point of groovy?
Is this actually how it's supposed to work in Netbeans? Without getting into an IDE war, do other IDEs do it better? everyone seems to rave about the Grails support in IntelliJ. Is it worth it?
One last point... I noticed that a regular war maven project no longer automatically reloads on an F11 build. Could this be related?
Thanks
--Matthias
Do not expect to have reloading for all your files even by running your grails app through command line.
Depending on which groovy file you have changed, grails run-time auto-reloading will work or not. Indeed:
Files and folders supporting reloading in development mode: gsp files (in view folder), grails services (in service folder), controllers, taglibs, css, i18 resources, javascript files, some config files (like Config.groovy), url mappings. Note that there are some Grails bug when for instance, using spring transactional annotation in Services makes the reloading crashed
Files and folders NOT supporting reloading (and requiring a restart of the application): any code under src/groovy, src/java, Domain classes (under domain directory), some configuration files, changes in plugins, any code under utils folder (if you have any Codec for instance)
So in your case, if you change a controller groovy file AND NetBeans restarts the application, I recommend you to use a separate command line for running grails application and using the IDE for code changes. The only bad side is that you will not use the NetBeans debugger.
Actually this is the way I work with Grails and IntelliJ
I'm using TJvPluginManager to build simple application with ability to load .bpl plugins. I have common interfaces declaration in "uIntfs.pas" file, which is kind of SDK ;)
The problem is, that if I try to load more than one plugin, the app throws an error:
Cannot load package 'test2'. It
contains unit 'uIntfs,' which is also
contained in package 'test'
It's quite obvious that BOTH bpls contain that file, however I need to make it work ...
Please help!
Put your uIntfs.pas into another BPL, and have your plug-ins both reference that BPL.
You'll have to do that for every unit that's common to both plug-ins.