How do I define the Assembly folder for an Application correctly?
I tried to use the registry Key:
HKLM/SOFTWARE/Microsoft/.NET Framework/AssemblyFolders/App-Name
and use the (Default) to set this to the path where the assemblies are located.
Some time ago this worked fine, but as I compiled a new Version and deployed it to a PC it wont work any more.
Do I have to add something else or missed any task?
Those registry keys are only used by visual studio for loading the references list and for helping with hint paths. Applications built on .Net use assembly loading rules which check for assemblies in the GAC, the application's private bin path, or some other subfolder under the private bin path. The .Net runtime does not use the registry to resolve assemblies at runtime.
If you are trying to add a reference on a machine that running 64-bit OS, than you need to add your App-Name under following registry key.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\AssemblyFolders\App-Name.
It's exactly like in your example, except that you need to add Wow6432Node key between SOFTWARE and Microsoft.
Related
I have a microsoft reporting server that i'd like to create some scriptcs against.
I know how to do this from within a VS project, by adding a web reference to some resource such as: https://rsdev1.myDomain/RSDEV1/ReportService2005.asmx
How does one accomplish this from a .csx?
thanks
I solved this by creating a vs project of type class library, then after copying this dll to my scriptcs bin folder it all works.
I've created an installer for my vb.net application and given it to a client to install, but it's getting a series of errors. I appear to have fixed most of them, but the one that's really causing an issue is one saying
Unable to install or run the application. The application requires that assembly CrystalDecisions.ReportAppServer.XmlSerialize Version 12.0.1100.0 to be installed in the Global Assembly Cache (GAC) first.
However, there is no GAC folder on the clients PC when looking in Windows\assembly
I've even searched the Local Disk for GAC, and the only folder results are GAC_MSIL, GAC_32 and GAC_64...
Where do I put this file to make the application work? Why is there not a GAC folder in the Windows\Assembly root?
The GAC folder for .NET 4.5 (and anything after 4.0) is here:
C:\Windows\Microsoft.NET\assembly
There are three folders beneath that (as you've found):
C:\Windows\Microsoft.NET\assembly\GAC_32
C:\Windows\Microsoft.NET\assembly\GAC_64
C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Where the assemblies should reside depend on which type of CPU(x86 or x64) they target. You shouldn't put assemblies in those folders yourself; they should be installed there by your deployment mechanism.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
When I add a file to my setup deployment project, Visual Studio won't allow me to edit the "SourcePath" to resolve an environment variable like $(DLL_PATH). It adds the file with the source path on my local machine and builds fine locally. When the same project is built on another machine, it won't work unless that machine also has the exact same path to files needed.
I want the SourcePath to resolve the $(DLL_PATH) so as long as a machine has it defined correctly the MSI package will build fine.
Not sure about the subst, since I have no control over what the other build machine looks like. If I try to assign a known directory to a virtual drive, it could possibly fail right?
Your best bet is to use subst.exe or a junction point to create a virtual directory. See here for information on junction points. Subst.exe simply creates a virtual drive letter. Put all of the deployable files in some directory tree with well-defined, constanct sub-paths, and make the root of that tree a junction point or virtual drive.
Actually what I did was setup a script.cmd to run after my project output is built to copy the dependencies to a folder that is relative to the actual project folder from the declared $(DLL_PATH). The setup project actually uses relative paths to the project, not absolute ones. So this works no matter what the build machine looks like. Then a script to remove this folder at the end.
I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.