I'm following the tutorial for http://mscrmshop.blogspot.be/2012/03/how-to-use-crmsvcutil-improved-version.html on autogenerating an XrmServiceContext file for Dynamics CRM 2011 development.
I have a solution with 3 projects. Each project has a slightly different namespace, depending on whether it's for Plugins, Workflows or the web portal. They all share the format company.software.productversion.module, and only module is different. I want to generate 1 file for each project and put them in the appropriate folders, but I only want to build this project once every time I change my CRM configuration, after which it builds 3 context files (1 for each namespace) and places it into the correct folders.
Is there a way to configure the config file for this project so this happens automatically?
There are multiple ways to do this. Probably the simplest is to have three different folders, each containing their own CrmSvcUtil and their own config file. Then in your Post Build Command line (or if you want to run it manually create a batch file), enter the paths to your 3 different CrmSvcUtil's:
"$(TargetDir)\Project1\CrmSvcUtil.exe"
"$(TargetDir)\Project2\CrmSvcUtil.exe"
"$(TargetDir)\Project3\CrmSvcUtil.exe"
Each one will run by itself with it's own settings, and can output it's own context file.
Related
My VStudio is 2019 Community, the application is an old VB Windows/Forms app being brought forward from .Net-3.5-ish to .Net-5.
Under .Net-4.8 or earlier, using the namespace System.Deployment.Application, one could access ApplicationDeployment.DataDirectory to locate that artificially-generated directory in \Users\Username\AppData\Local\Apps\2.0\... that a 1-click installation would create and populate with data files from the Project Build/Publish.
Under .Net-5, I believe that particular set of functions has been taken out - yet the ClickOnce installer still places Data files there. How do I programmatically locate that directory? The Application Path can be located from System.AppContext.BaseDirectory, but that doesn't help in locating the data.
This app, an old bit of VB code, has a large number of application data files that need to be installed along with the code. As there are more than 40 of them, we've kept them in their own \Data directory, which is included in the Project, is under Git control to keep their versions aligned with their code...
In an uninstalled app, we could keep this \Data directory adjacent to the executable, and find it easily at runtime: but with a ClickOnce installed app, that falls apart. In the Publish configuration, all the data files are identified, with Group=Required, Publish Status=DataFile.
Can I either:
Easily configure the 1-click installer to place our \Data directory and its contents into one of the standard \Local\Appname or \Roaming\Appname directories that seem to also get created, but left empty? Those can easily be located at runtime.
Easily construct at runtime the path to that obscure data directory that 1-click normally creates and uses for data?
Cheers, and Thanks! Bob
I need to read the settings file (appsettings.json) from another project in my solution. When I use:
Directory.GetCurrentDirectory()
From within the current project, I get the following path:
{projectRootFolder}\bin\Debug\netcoreapp3.0\
My question is: How can I get to the exact same folder in another project in the same solution? Or is there a better way to access the settings file from another project within the current solution?
If I understand the problem correctly there are two misconceptions:
It has little sense to access output directory of an another project as the structure has sense in compile time only. You will not have the same structure in run-time once the application is "published".
The Directory.GetCurrentDirectory() returns the current working directory. It is just a coincidence to be set to project output directory by Visual Studio. It can be totally different directory.
It is not clear to me what exactly you are trying to achieve. I recommend using the configuration system provided by .net core to access the configuration and add that other appsettings.json as another configuration provider.
If you really need to open the settings file then the project with the settings file (A) should mark the file as "Copy to Output Directory" and the project to open the file (B) should reference the project A. So the settings file will be copied to output of the project A too.
What you're attempting to do is not possible. There's no inherent way for ASP.NET Core to know where a totally different app running in a totally different process is located.
If you need to access appsettings.json from another project, then you would need to include it as a linked file in your project, and set it to copy to output. Then, you're accessing it actually from your project (which is all you can do), but the file itself is shared.
However, this is almost always a bad idea, and usually a sign that you're doing something wrong. If you truly do need to share the settings, then what you should be doing is putting them in a distributed config provider like Azure Key Vault or similar, where both projects can independently access the settings from a common store.
I have written a program on Visual Basic. In the debug folder, there are many files:
Database1.mdf
Database1_log.ldf
MyData.Designer.vb
MyData.xsc
MyData.xsd
MyData.xss
WindowsApplication1.exe
WindowsApplication1.config
WindowsApplication1.pdb
WindowsApplication1.vshost
WindowsApplication1.vshost.exe
WindowsApplication1.vshost.exe.manifest
WindowsApplication1.xml
I want to publish my program. Are all of those files necessary for the program? Which of them are used for my database?
Because I want to put a button in my program that backs up the database. Which files must be backed up?
First of all, you should publish the Release version of your software, not the debug version so the files will be a bit different. As for which files to publish, if you use the Setup project you will be able to select the files based upon what your application needs. For example, it looks like you are including database files with your application (Database1.mdf and Database1_log.ldf). You could add these files to the setup project.
The setup project will know to include your exe and your config file (unless you tell it not to) so you will be covered there. Here is a video and a written walkthrough of how to create a Setup project:
http://msdn.microsoft.com/en-us/library/ms241903.aspx
http://www.youtube.com/watch?v=Lcue0jo41AM
As for your PDB files, these are the Program Database Files that are used for debugging (and should never be give to the customer/end user).
http://msdn.microsoft.com/en-us/library/ms241903.aspx
As for backing up your database, back up the MDF and LDF files.
No, all of the files above are from your debug compile output. You can change what is output by changing your build configuration. Go to Build, Configuration Manager and switch to Release. It's also on the toolbar.
In general your ProjectName.exe (but not the .vshost.exe), .config (but not the .vshost.exe.config) and MDF/LDF files are needed for publishing. You also have an XSD File which will also be needed.
The MDF/LDF files are your database.
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
Seeing as the hibernate.cfg.xml file has to be in the running application (in this case a web application), what is the best way to have the file in both my test project and my web app project?
You can add the file to multiple projects. If you use visual studio you can right click one of the projects and than add existing item. Click on the arrow on the right of the add button. Click on "add as link" The same file is added to both the projects now.
I don't recommend to use the same database for automatic tests, because the tests will run slow and it will be difficult to ensure the state of the database before each test.
I'd suggest that you place the xml file into a seperate directory and link/share the file. You can refer to DimeCasts.net for more information. www.dimecasts.net/Casts/CastDetails/10
The easiest way is to just put a copy of the XML file in both projects. You'll just have to be careful to keep all the configuration settings in synch in both places. This will allow for easy debugging within the test project or web app. If you have a build system setup, which creates deployments for testing, you could store the xml file in a common location, then create a build action to copy it to the output directory of both projects when you go to deploy/test.